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FOREWORD 

NASA/Goddard Space Flight Center (GSFC), in cooperation with the AIAA Technical Commit- 
tee on Computer Systems, sponsored this workshop on Aerospace Applications of 
Microprocessors. The rapidly increasing capabilities and decreasing costs of digital computing 
systems in general, and microprocessors in particular, have meant orders of magnitude increases 
in their use in aerospace systems, particularly onboard satellites and aircraft. 

The objectives of the workshop were to assess the state of microprocessor applications and to 
identify current and future requirements and associated technological advances which allow 
effective exploitation of this rapidly advancing technology. There were four sessions in the 
workshop: 

I. Air/Space Applications of Microprocessors; 

II. Ground Based Aerospace Microprocessor Applications; 

III. Microprocessor Software Technology; and 

IV. Microprocessor Hardware Technology. 

This document contains only a synopsis and key figures of each presentation. The synopses and 
figures were submitt^^ as camera-ready copies prior to the workshop. Only minor editorial 
changes have been made. 

In addition to the formal presentations, the workshop was structured to provide time for audi- 
ence interaction. On the evening of November 3^ a panel discussion on “Are Microprocessor ^ 
Trends and Aerospace Requirements Heading in the Same Direction?”, was held. The panelists 
were: 

Terry Straeter, General Dynamics Data Systems Service, (Moderator); 
RockyA.Evahs,MilitaryProductsManager,InteTCorporation; 

Adrian Hooke, Jet Propulsion Laboratory; 

Charles Husson, Langley Research Center; and 

John Shea, Vice-President Integrated Circuit Electronics. 

The workshop was organized by a subcommittee of the AIAA technical committee on computer 
systems. Co-chairrhen were: 

John Sos, Goddard Space Flight Center 

Terry Straeter, General Dynamics Data Systems Services. 

Other committee members were: 

M. Kelly, Sperry Flight Systems; 

T. McTigue, McDonriell Douglas Aircraft; 

R. Schwartz, McDpnnell Douglas Astronautics; and 
T. Smith, NAVAIR Systems Command; and 

NASA/GSFC members were: 

E. Connell 
R. Nelson. 

Use or identification of commercial products in this document does not constitute an official en- 
dorsement of such products or their manufacturers, either expressed or implied, by NASA. 


John Y. Sos 
Program Co-chairman 
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AN IMAGING INFRARED (HR) SEEKER USING A 
MICROPROGRAMMED PROCESSOR 

Kerry V, Richmond 
McDonnell Douglas Astronautics Co. 

St. Louis, Missouri 


A recently developed IIR seeker uses a microprogrammed processor to 
perform gimbal servo control and system interface via a MIL-STD 1553 port 
while performing the seeker functions of automatic target detection, acquisi- 
tion and tracking. Although the acquisition and centroid tracking are 
relatively low computation load seeker modes, the automatic detection mode 
requires up to 80% of the available capability of a high performance 2900 
based microprogrammed processor. With the high speed processing capability 
available it is possible to implement a digital servo in the same processor 
using only 5% of the computation capacity. This digital servo includes six 
modes of gimbal control at the basic processor 60 Hz computation loop plus a 
200 Hz rate loop, the latter being transparent to the main seeker functions. 
These two asynchronous timing loops plus a 50 Hz system interface loop driven 
from the 1553 port are implemented in the one processor. The fast response 
required by the rate loop for the rate sensor demodulator inputs also requires 
an interrupt driven analog data acquisition system. A 4K microcode program 
driven by eight interrupts implements these functions as well as the other 
operator and system interfaces. 

The eighth interrupt is used to force the processor into special "front . 
panel" code which suspends all other interrupt processing and saves the 
state of the processor to allow the programmer to view the contents of all 
registers and memory as well as enter new values and resume normal processor 
execution at the interrupted location or any other selected location. This 
programmer debug aid in the hardware coupled with a set of support software 
including a symbolic cross assembler and a software simulation of the 2900 
based processor allow efficient program development and checkout. 

This system developed around the microcoded processor required by one 
of the system tasks has been designed, checked out and flown successfully. 
Although system complexity was increased significantly by adding the addi- 
tional functions this approach can be cost effective when the basic computa- 
tion capacity is already available. 
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CPU PERFORMANCE/REQU I REGENTS 
0 2900 BIT SLICE MICROPROGRAflMED PROCESSOR 
0 A8 BIT WIDE MICROCODE WORD 
0 267 NANOSECOND CYCLE TIME 
0 PROGRAM MEMORY ‘ 

0 2K SCRATCH PAD MEMORY 
0 8 INTERRUPTS 


SEEKER INTERRUPTS 

SYSTEM INTERRUPTS 
0 CONTROL PANEL 
0 A/D COMPLETION 
60 Hz MAIN LOOP 
: 0 END OF GATE 

0 END OF FIELD 
200 Hz SERVO RATE LOOP 

0 SAMPLE AZIMUTH DEMODULATOR 
0 SAMPLE ELEVATION DEMODULATOR 
50 Hz GUIDANCE COMPUTER TIMING LOOP 
0 1553 INPUT DATA READY 
0 1553 OUTPUT DATA READY 
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EIGHT MICROPROCESSOR-BASED INSTRUMENT DATA SYSTEMS IN THE 
GALILEO ORBITER SPACECRAFT* 

Robert C. Barry 
Jet Propulsion Laboratory 
Pasadena, California 


The Galileo Orbiter spacecraft carries nine scientific instruments, 
all but one of which are controlled by individual microprocessors. Scientific 
investigations include interplanetary measurements of charged atomic particles , 
magnetic and electric fields, and dust. In orbit, Galileo will investigate 
Jupiter’s magnetosphere and atmosphere; and surface properties of the four 
largest satellites. Launch is scheduled for early in 1984. 

While the. complexity of the instruments and their data systems varies widely, 
all utilize components from the RCA 1800 microprocessor family, and all perform 
the same basic functions. The decisions to utilize microprocessors in the 
instruments were heavily influenced by the spacecraft distributed Command and 
Data System (CDS) design which uses this same LSI family. 

A typical instrument data system consists of a microprocessor, 3K Bytes of 
Read Only Memory (ROM) and 3K Bytes of Random Access Memory (RAM) . It interfaces 
with the spacecraft data bus through an isolated user interface with a direct 
memory access bus adapter. Microprocessor control and data lines provide 
interrupts, serial, and/or parallel data from instrument devices such as registers, 
buffers, analpg to digital converters, multiplexers, and solid state sensors. 

These data systems support the spacecraft hardware and software communication 
protocol, decode and process instrument commands, generate continuous instrument 
operating modes, control the instrument mechanisms, acquire, process, format, 
and output instrument science data. 

The approach has resulted in many specific improvements over past missions. 
Some of the most important include: increased instrument autonomy, functional 

commanding, and macro mode generation; enhanced telemetry output from both 
operational and scientific points -of -view; and additional flexibility for in- 
flight optimization, problem work-arounds, and instrument generalization for 
support of multiple missions. 

There was a significant but manageable underscoping of the microprocessor 
development tasks and costs. This was related to difficulty in establishing 
firm requirements at an early date, interfacing complexity, parts acquisition 
problems, and a general lack of extensive experience in microprocessor hardware 
and software design. 

While the Galileo entry-level introduction into instrument microprocessor 
appears to be proceeding well, additional effort is needed for standard use of 
microprocessors in science instruments to achieve a significant part of its high 
potential benefit. This includes generation and clarification of spacecraft system 
level requirements in concert with the objectives of the end-to-end information 
system design, improved use of microprocessor development tools and practices, 
and justification for increased instrument funding compatible with the increase 
in capability and cost. 

*This work was performed for the Jet Propulsion. Laboratory, California Institute of 
Technology, sponsored by the National Aeronautics and Space Administration under 
Contract No. NAS7-100. 
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OF CDS) 


INTRODUCTION 


• HISTORICAL ASPECTS OF INSTRUMENTS ON JPL SPACECPuAFT 

• INCREASING COMPLEXITY 

• HIGHLY INTEGRATED SPACECRAFT 

• HIGHLY INTEGRATED MISSION OPERATIONS S FLIGHT TEAM 

• EXTENSIVE DATA PROCESSING & CORRELATION THE NORM 

• WHAT ROLE DO INSTRUMENT MICROPROCESSORS PLAY IN THIS? 

• NOT A DRAMATIC CHANGE. A NATURAL EVOLUTION 

• VERY FLEXIBLE. EXPANDABLE CONCEPT 

• GALILEO IS THE STARTING POINT 

• LIMITATIONS OF THIS PRESENTATION 

• RESTRICTED TO A HIGH-LEVEL. BRIEF REVIEW 

• TIME RESTRICTIONS FORCE GENERALIZATION 

• ACCENTUATE COMMON ELEMENTS 

• LITTLE DISCUSSION OF UNIQUE IMPLEMENTATIONS 


MATERIAL TO BE COVERED 

• REASONS FOR USE OF MICROPROCESSOR-BASED DATA SYSTEMS IN THE INSTRUMENTS 

• FUNCTIONS PERFORMED BY THE uPs 
$ SUMMARY OF THE INSTRUMENTS 

• SELECTED HIGHLIGHTS FROM THE GALILEO APPLICATIONS 

• PROBLEM AREAS ENCOUNTERED 

• EVALUATION OF THE GALILEO APPROACH 
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WHY USE MICROPROCESSORS IN THE GALILEO INSTRUMENTS? 

• SUPPORT THE GENERALIZED SPACECRAFT SYSTEM INTERFACE (BUS) 

• PROVIDE INCREASED INSTRUMENT AUTONOMY 

t REDUCE REQUIREMENT FOR SPACECRAFT SERVICES 

• INCREASE INSTRUMENT DESIGN CONTROL 

• UTILIZE SEMICONDUCTOR INDUSTRY ADVANCES 

• AVAILABLE/ PROVEN LSI PRODUCTS (RCA CDP1800 SERIES) 

• DECREASE POWER AND MASS REQUIREMENTS (CMOS LSI) 

• INCREASE RELIABILITY (REDUCE PARTS COUNT) 

• SIMPLIFY DESIGN (REPLACE DISCRETE, MSI LOGIC) 

• EXTEND INSTRUMENT CAPABILITY (FALLOUT, NOT A REQUIREMENT) 

• ADD FLEXIBILITY TO ACCOMODATE CHANGING REQUIREMENTS (SOFTWARE) 
t PROVIDE ENHANCED MODE GENERATION AND CONTROL (MINIMAL H/W) 

• GENERALIZE INSTRUMENT 

0 MODIFY OR UPGRADE FOR FUTURE USE ON OTHER SPACECRAFT 


INSTRUMENT DATA SYSTEM FUNCTIONS 
0 SUPPORT SPACECRAFT INTERCOMMUNICATION BUS AND PROTOCOL 
0 DECODE AND PROCESS INSTRUMENT COMMANDS 
0 GENERATE INSTRUMENT OPERATING MODES 
0 CONTROL MECHANISMS . 

0 PROCESS SCIENCE DATA FOR OUTPUT 
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DATA SYSTEM FUNCTIONS 

• SUPPORT OF SPACECRAFT BUS AND PROTOCOL 

• SERIAL, SYNCHRONOUS DATA AT ^ 03. 2 KBPS 
t ISOLATED USER INTERFACES (TRANSFORMERS) 

• MEMORY TO MEMORY TRANSFER USING DIRECT MEMORY ACCESS 

• S/C COMIiAND DATA SYSTEM (CDS) INITIATES. AND CONTROLS ALL ACTIVITY ON A TIME 
MULTIPLEXED BASIS 

t DECODING AND PROCESSING OF INSTRUMENT COMMANDS 

• ACCOMODATE VARIOUS INPUT DATA 

0 COMMANDS 
0 MEMORY LOAD 
0 S/C TIME AND SPIN DATA 
0 PROCESS COMMANDS : 

0 ERROR CHECKING & VALIDATION 
0 UPDATE OF INSTRUMENT STATE DATA 

DATA SYSTEM FUNCTIONS (CONT'D) 

0 GENERATION OF INSTRUMENT, OPERATIONAL MODES 

0 ALLOW FUNCTIONAL LEVEL COMMANDING (TYPICALLY 3 TO 8 MAJOR MODES) 

0 REDUCE INTER-SUBSYSTEM COMMUNICATION 

0 SYNCHRONIZE WITH SPACECRAFT TIMING 

0 PROVIDE MORE MODE GENERATION FLEXIBILITY TO THE INSTRUMENT 

0 MECHANISMS CONTROL FUNCTIONS (SENSORS, FILTER WHEELS, MULTIPLEXERS, ETC.) 

0 SENSE MECHANISM STATUS 
0 GENERATE CONTROL SIGNALS 
0 ACQUIRE AND BUFFER DATA 

0 SCIENCE DATA PROCESSING 

0 APPLY ALGORITHMS TO PROCESS DATA (COMPRESSION, STATISTICS, DE-SPIN, ETC.) 

0 FORMAT DATA (CONTROL SUBCOMMUTATION, ADD ENGR &. STATUS, ETC.) 

0 OUTPUT TO BUS UPON REQUEST 
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INSTRUMENT SUMMARY 


ABBR. 

NAME 

PRINCIPAL INVESTIGATOR 

INSTITUTION 

SSI 

SOLID STATE IMAGING 

DR. J.S. BELTON, 
(TEAM LEADER) 

KIT PEAK NATIONAL OBSERVATORY, 
TUSCON, AZ 

NIMS 

NEAR INFRARED MAPPING 
SPECTROMETER 

DR. R. CARLTON, 
(TEAM LEADER) 

JET PROPULSION LABORATORY, ^ 
PASADENA, CA 

PPR 

PHOTOPOLARIMETER 

RADIOMETER 

DR. J.E. HANSEN 

GODDARD INSTITUTE FOR SPACE STUDIES, 
NEW YORK, NY 

UVS 

ULTRAVIOLET SPECTROMETER 

DR. C.W. HORD 

LABORATORY FOR ATMOSPHERIC AND SPACE 
PHYSICS, BOULDER, CO 

EPD 

ENERGETIC PARTICLE DETECTOR 

DR. D.J. WILLIAMS 

NOAA SPACE ENVIRONMENT LABORATORY, 
BOULDER, CO 

PLS , 

PLASMA SUBSYSTEM 

DR. L.A. FRANK 

UNIVERSITY OF IOWA, 
IOWA CITY, IOWA 

iMAG 

MAGNETOMETER 

DR. M. KIVELSON 

UCLA 

LOS ANGELES, CA 

DOS 

DUST DETECTOR SUBSYSTEM 

DR. EBERHARD GRUN 

MAX PLANCK INSTITUT FUR KERNPHYSIC, 
HEIDELBURG, WEST GERMANY 

PWS 

PLASMA WAVE SUBSYSTEM 
(NO uP) 

DR. D.A. GURNETT 

UNIVERSITY OF IOWA, 
IOWA CITY, IOWA 


INSTRUMENT COMPLEXITY COMPARISON 



ROM 

RAM 

TELM DATA 

DATA 

NO 

COMMAND 

NO 

NO 

MASS 

PWR 

INST 

KBYTE 

KBYTE 

(KBPS) 

MODES 

PARMS. 

MECHANISMS 

SENSORS 

(KG) 

(WATT) 

SSl' 

3 

3.5 

768. TO 0.02- 

3 

2A 

9 

800 X 800 CCD 

. 28.0 

25. 

NIMS 

3 

1.75 

11.52 

6 

31 

9 

17 

18.1 

16. 

PPR 


0.25 

0.18 

5 

12 

10 

3 

A. 3 

12. 

UVS 

— 

0.75 

1.0 

3 

20 

6 

3 

A. 2 

A. 5 

EPD-1 

A 

2.66 

0.92 

15 

150 

50 

17 - 

8.5 

8.6 

EPD-2 

2 

0.25 

— 

— 

50 

3 

— 

(TNCL ABOVE) 

PLS-1 

A 

A 

0.6 

7 

lAO 

31 

20 

10.7 . 

9.5 

PLS-2 

DDS 

(SAME AS PLS-1) 
3.2 

.02 A 

3 

33 

9 

A 

A.O 

1.8 

PWS 

— 

0.25 

6A5., TO 0.2 

2 

7 

11 

3 

5.3 

5.6 

(NO kP) 
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INSTRUMENT DATA SYSTEM HIGHLIGHTS 
(SELECTED FROM AMONG THE EIGHT INSTRUMENTS) 

1) FUNCTIONAL COMiMANDING AND MACRO MODE GENERATION 

2) TASK ALLOCATION BETWEEN MICROPROCESSOR AND OTHER INSTRUMENT HARDWARE 

• HIGH RATE DATA TRANSMISSION 

• SPECIALIZED PROCESSORS (FORMATTERS, MULTIPLIER, ENCODER/COMPRESSOR,, ETC.) 
e SOFTWARE OVERALL CONTROL 

• HYBRID INSTRUMENT OPERATION (WITH OR WITHOUT uP) 

3) ENHANCED DATA ACQUISITION & TELEMETRY OUTPUT 

• SUBSYSTEM UNIFORMITY 

• ADDED ENGINEERING VISIBILITY (SPECIAL HIGIl-RATE MODES, SUBCOMS, ETC.) 

• SOME ADDITIONAL ON-BOARD PROCESSING & BUFFERING (DATA DISCRIMINATION, DATA SEARCH, 

OPTIMUM AVERAGING, COMPRESSION, ETC.) 

4) MEMORY RE-ALLOCATION AND REPROGRAMMABILITY FOR SCIENCE MODE OPTIMIZATION AND RESPONSE 
TO SUBSYSTEM OR SPACECRAFT FAILURES 

• RAM MARGIN 

• RAM REPLACEMENT OF ROM VIA BUS COMMAND 

• ROM LINKAGES TO RAM FOR SUBROUTINE REPLACEMENT 


INSTRUMENT DATA SYSTEM HIGHLIGHTS (CONT'D) 


5) HIGHLY FLEXIBLE APPROACH 

• ALLOWS SUBSYSTEM OPTIMIZATION 

• WIDE RANGE OF DATA RATES 

• 8 UNIQUE DESIGNS 

6) CLEAR BENEFIT IN LOGIC REPLACEMENT OBSERVED 

J) ADVANCED DATA SYSTEM TECHNIQUES 

• MULTIPLE MICROPROCESSORS 

• POWER HSARING, FAILURE ISOLATION 
t AUTO-CALIBRATION 

• BACKGROUND PROCESSING, HIGH LEVEL LANGUAGE (FORTH) 

8) COMPATABLE WITH LONG-RANGE DEEP SPACE EXPLORATION DESIGNS AND GOALS 

• PACKET TELEMETRY 

• ADDED AUTONOMY 

• EEIS 
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PROBLEM AREAS ENCOUNTERED . 

1) HARDWARE DESIGN LIMITATIONS AND CONSTRAINTS 

• SPACECRAFT MASS, POWER, AND RELIABILITY REQUIREMENTS 

• LIMITED OPTIONS IN uP AND CHIP FAMILY SELECTION (1802, 1852, 1856, 183A 
TC2AA) 

• LIMITED MEMORY SIZE (RAM IS 256 x ^ BITS) 

. • JUPITER MISSION REQUIRED HIGH RADIATION TOLERANCE ' 

• PARTS DEVELOPMENT AND ACQUISITION PROBLEMS . 

• CAUSED INCREASED COST, SCHEDULE PROBLEMS 

2) USE OF READ ONLY MEMORY (ROM) AS PRIMARY PROGRAM MEMORY 

• INCREASED COSTS AND SCHEDULING PROBLEMS 

• DECREASED FLEXIBILITY 

• INCREASED NEED FOR EARLY SYSTEM-LEVEL VALIDATION 

3) UNDERSCORING OF MICROPROCESSOR DEVELOPMENT TASKS AND COSTS 

• SOFTWARE, SOFTWARE MANAGEMENT AND DOCUMENTATION 

• DEVELOPMENT SYSTEMS AND SUPPORT EQUIPMENT 

• INTERFACE REQUIREMENTS STABILITY 

• ADDED TESTING COMPLEXITY 


PROBLEM AREAS ENCOUNTERED (CONT'D) 


A) BUS DESIGN 

• BUS ADAPTER COMPLEXITY 

• LOW ERROR REQUIREMENT 

• OPEN-LOOP PROTOCOL (NO HANDSHAKE) 

5) SYSTEM LEVEL REQUIREMENT IMMATURITY 

• END-TO-END INFORMATION SYSTEM (EEIS) GOALS REDUCED 

• EARLY INTERFACE REQUIREMENT STABILITY AND DETAILED DESCRIPTION 

6) PERSONNEL EXPERIENCE AND TRAINING 

• yP 

• SOFTWARE 



EVALUATION OF THE GALILEO APPROACH 

) 

• CURRENT STATUS 

0 MOST INSTRUMENTS HAVE AN OPERATIONAL BREADBOARD DATA SYSTEM NOW 
0 EXPECT ON-TIME DELIVERY OF ADVERTISED CAPABILITY 

0 EXPECT TO SIGNIFICANTLY ENHANCE THE SCIENCE VALUE OF THE MISSION 

0 EACH INSTRUMENT PROVIDES SCIENCE OPTIMIZATION FOR ITS INVESTIGATORS 
0 EACH HAS PROVIDED FOR INCREASED IN-FLIGHT FLEXIBILITY 

0 ADDITIONAL EFFORT MUST BE EXPENDED TO SOLVE PROBLEMS ASSOCIATED WITH: 

. 0 SYSTEM REQUIREMENTS DEFINITION 
0 IMPROVED USE OF MICROPROCESSOR DEVELOPMENT TOOLS 
0 FUNDING CONSISTENT WITH THE ENHANCED CAPABILITY AND COST 


FUTURE PROJECTIONS 

0 TECHNOLOGY IMPROVEMENT 

0 SEMICONDUCTOR TECHNOLOGY (ADVANCED yP. DENSE MEMORY. HIGHER SPPED. ETC.) 

0 ADVANCED ARCHITECTURE AND SOFTWARE DESIGN (MULTIPLE MICROPROCESSORS. 

HIGH LEVEL LANGUAGES. ETC.) 

0 APPLICATION ADVANCES 

0 INSTRUMENT AUTONOMY 
0 HIGHLY FUNCTIONAL COMMANDING 

0 EXTENSIVE ON-BOARD PROCESSING (ESPECIALLY FRONT-END APPLICATIONS) 
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A COMMAND & DATA SUBSYSTEM FOR DEEP SPACE EXPLORATION BASED ON 
THE RCA 1802 MICROPROCESSOR IN A DISTRIBUTED CONFIGURATION 

Jack S. Thomas 

California Institute of Technology 
Jet Propulsion Laboratory 
Pasadena, California 


The Conmand and Data Subsystem (CDS) is an RCA 1802 CMOS microprocessor-based 
subsystem that acts as the central nervous system for the Galileo Orbiter 
Spacecraft. All Communication between the ground and spacecraft flows through 
the CDS. The CDS also distributes commands in real time, algorithmetical ly 
expanded from a data base loaded from the ground and in response to spacecraft 
alarms. 

The distributed microprocessor system is configured as a redundant set of 
hardware with three microprocessors on each half. The microprocessors are 
surrounded by a group of special purpose hardware components which greatly 
enhance the ability of the software to perform its task. 

The presenter shows how the software architecture makes a distributed system 
of six microprocessors appear to each user as a single virtual machine, and 
collectively as a set of cooperating virtual machines that prevent the simul- 
taneous presence of the several users from interfering destructively with each 
other. 






















GALILEO CDS FLIGHT 
HARDWARE CONFIGURATION 
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GALILEO CDS FLIGHT SOFTWARE ARCHITECTURE 



ACCESS 



HLM PROCESSOR TIME ALLOCATION 


1. FOREGROUND EXECUTIVE 

2. ADMINISTRATIVE PROGRAMS 

3. IMMEDIATE ACTION COMMAND PROGRAM 

4. FAULT PROTECTION PROGRAMS 

5. ENGINEERING SEQUENCE PROGRAMS 

6. SCIENCE SEQUENCE PROGRAMS 

7. DELAYED ACTION COMMAND PROGRAMS 

8. PROCESSOR TIME MARGIN 
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SYNERGISTIC INSTRUMENT DESIGN 

Dale E. Winter 
Jet Propulsion Laboratory 
Pasadena, California 


I. The Synergistic Approach 

A. Do a functional design 

1. Block-out all system functions. 

2. - Identify all areas that are exclusively analog. 

3. Identify all areas that are exclusively digital. 

4. Identify any analog/digital hybrid areas. 

B. Design hardware to promote efficient software. 

1. Supply task-efficient timing. 

2. Supply task efficient I/o structures. 

3. Design a task/code efficient system architecture. 

C. Design software to promote efficient hardware. 

1. Structure software to minimize hardware. 

2. Customize coding to be task efficient. 

3. Directly replace hardware functions wherever possible. 

4. Use time and memory space wisely. 

D. Completed design yields bonuses. 

1. Additional features can be included with nominal hardware 
increases. 

2. Design changes can be made easily. 

3. Less hardware means less power, less mass and fewer failures. 
II. The Galileo Television Camera 

A. Taking pictures. 

1. Filter selection and shuttering with software timed pulses 
directly to mechanism drive amplifiers. 

2. CCD readout HI rate timing executed in hardware. 

3. CCD readout LO rate timing and video/data system time 
syncronization executed in software. 

4.. Software timing is precision synchronized with system 
clock to assure exposure accuracy. 

B. Telemetry acquisition. 

1. Software controlled ADC and Mux. 

2. Precision sample times. 

3. Software can position sample times anywhere within the camera 
cycle to monitor specific activities. 
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C. Communications 

1. Non-immediate bus adapter does most work in software.. 

2. Software sequencing sync's up with time broadcast. 

3. Software rate buffers telemetry for transmission. 

D. In-flight, problem solving. 

1. Programmable telemetry can profile electrical activity. 

2. Multi-mode memory switching and mixing. 

3. In-flight re-programming capability.. 

4. Diagnostic software reports and time tags errors. 

SSI Timing 

SSI image parameter control and timing signal generation is based 
on applicat.on of microcomputer technology. In addition to 
controlling serial pixel shifting and pixel analog-to-digital con- 
version, all timing, sequencing, mechanism control, engineering 
and status data acquisition, and buffering shall be performed under 
programmed microcomputer control. SSI data rates and formats shall 
be as specified in GLL-3-280., Telemetry Measurements and Data 
Formats. Additional SSI rates and timing intervals are presented 
in Table 1. Figures 2A, 2B and 2C present the relationship between 
the various SSI timing parameters for SSI imaging modes of 8 2/3, 

30 1/3 and 60 2/3 seconds respectively. 


TABLE 1. SSI TIMING PARAMETERS 




8 2/3 Second 
flode 

30 1/3 Second 
Mode 

60 2/3 Second 
Mode 

a. 

Pixel bit rate 

806.4 KBPS 

806.4 KBPS . 

806.4 KBPS 

b. 

Pixel rate 

100. 8K Pixels/s 

100. 8K Pixels/s 

100. 8K Pixels/s 

c. 

Line time 

8 1/3 m sec 

33 1/3 m sec 

66 2/3 m sec 

d. 

Read frame time 

6 2/3 sec 

26 2/3 sec 

53 1/3 sec 

e. 

Frame repetition 
time 

8 2/3 sec 

30 1/3 sec 

60 2/3 sec 

f. 

Prepare time 

2.0 sec 

3 2/3 sec 

7 1/3 sec 

g- 

Filter steps 
allowed 

2 

3 

7 

h. 

Maximum normal 
exposure 

800 m sec 

800 m sec 

800 m sec 

i . 

Maximum extended . 
exposure 

6400 m sec 

25600 m sec 

51200 m sec 

j. 

SSI reply data rate 

403.2 KBPS 

403.2 KBPS 

403.2 KBPS 

k. 

CDS sync 

806.4 KBPS 

806.4 KBPS 

806.4 KBPS 

1. 

Real-time interrupt 

15 Hz 

15 Hz 

15 Hz 



CDS flash 
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FLASH HEATER POWER 
REPt. heater POWER 
SSI POWER 

OniCS HOOD DEPLOY 

onics HOOD r&Mp. 

FRONT OPTICS TEMP. 

REAR OPTICS TEMP. 

PIXEL DATA 1 <4MSB‘S) 

PIXEL DATA 2(4L58'S) 

PIXEL BIT SYNC (403.2kHx) 
PIXEL WORD SYNC 
RADIATOR PLATE TEMP. 

CCD HOUSING TEMP. 

CDS SYNC (606. 4kHz) 
real time INTERRUPT (IS Hi) 
SUPERVISORY DATA 
SSI reply DATA 
RONT ELECTRONICS TEMP. 
rear ELECTRONICS TEMP. 

CDS SYNC 

real time INTERRUPT 
SUPERVISORY data 
SSI REPLY DATA 
PIXEL' ENABLE 
PIXEL BIT SYNC 

NORMAL PIXEL DATA I (4MS6'S) 


NORMAL PIXEL DATA 2 (4LSB*S) 
NORMAL PIXEL WORD SYNC 


COMPRESSED PIXEL DATA I (4MSB‘S) 
COMPRESSED PIXEL DATA 2 (4LSB*S) 
COMPRESSED PIXEL wORO SYNC 


COS 


OiREa 

ACCESS 


FIGURE 1. SSI FUNCTIONAL BLOCK DIAGRAM 
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REQUIREMENTS 

COMMUNICATE VIA CDS BUS PROTOCOL 
MEET CAMERA FUNCTIONAL OBJECTIVES 
PREVENT HAZARDOUS CONDITIONS 
PROVIDE CAMERA HEALTH DATA 
PROVIDE FOR BACK-UP MODES 
PROVIDE FOR POST LAUNCH REPROGRAMMING 
PROVIDE DIAGNOSTIC TOOLS 

CXtliloo 

DESIGN CRITERIA 

• FUNCTIONAL REQUIREMENTS 

• CIRCUIT STIMULATION REQUIREMENTS 

• COMMUNICATIONS REQUIREMENTS 

• TIMING CONSIDERATIONS 

• HARDWARE/SOFTWARE TRADEOFFS 

• DIAGNOSTICS 

• FAULT. DETERMINATION 

• REPROGRAMMING TECHNIQUES 


DESIGN APPROACH 

• EFFICIENT PROGRAM ARCHITECTURE 

• OPTIMAL MEMORY USAGE AND EXECUTION TIMES 

• ERRONEOUS COMMAND PROTECTION 

• PARITY ERRORS/ILLEGAL COMMANDS 

• CONTINUOUS DIAGNOSTICS 

• CHECKSUMS/SCRATCH-PAD WRITE-READ 

• FAULT DATA IN TELEMETRY . 

• PARITY ERROR, COMMAND TRAFFIC, ILLEGAL 
COMMAND COUNTS 

• DIAGNOSTIC RESULTS/FAULT TIME TAG ■ 

• SPECIAL FAULT;ANALYSIS TOOLS 

• PROGRAMMABLE ENGINEERING READOUTS 

• PROGRAMMABLE MEMORY MONITOR 

• BACK-UP MEMORY CONFIGURATIONS 

• EXECUTE CODE FROM. RAM, ROM + RAM, ROM/RAM + 
SCRATCH -PAD 

USE SPARE SCRATCH -PAD FOR CODE OR DATA 


\i\Tlifoo 

DATA SYSTEM ARCHITECTURE 

• OUTPUT PORTS SUPPLY LOW AND MEDIUM RATE PULSES AND 
SIGNALS TO CAMERA ELECTRONICS 

• SOFTWARE DISPATCHES AND TIMES OUTPUTS IN ACCORDANCE 
WITH COMMAND, FUNCTIONAL AND ELECTRICAL REQUIREMENTS 

• INPUT PORTS SUPPLY ENGINEERING, FILTER POSITION AND 
STATUS DATA TO THE SOFTWARE 


• FLAGS SUPPLY RTI, PROGRAM LINK MODE, SRTl PHASE AND 
CDS BUS PARITY ERROR DATA TO THE SOFTWARE 


• SOME OUTPUTS ARE RE-CLOCKED WITH SRTl OR SRTl PHASE 
TO ASSURE SYSTEM SYNCHRONISM 



OXiHfco 

SSI MICROCOMPUTER 



INITIATE parallel transfer 
PIXEL enable 
PARALLEL DIRECTION . 

ERASE RATE 
SOURCE/SINK 
SHUTTER RESET 
SHUTTER OPEN 
SHUTTER CLOSE 


ENGR MUX 0 
ENGR MUX 1 
ENGR MUX 2 
ENGR MUX 3 
ENGR ADC START 
GAIN NORMAiy^X 
FILTER WHEEL STEP 
FILTER POSITION read 


FILTER WHEEL POSN ? 
FILTER WHEEL POSN 2 
FILTER WHEEL POSN 3 
FILTER WHEEL POSN P 
SCRATCH PAD 1 OR 2 
ROM, 'll AM 
S/N I 
S/N 0 


ENGR 
ADC 
DATA 
(8 SITS) 


CCD 

TIMING 

AND CONTROLS 


BUS ADAPTER CONTROL 



SHUTTER CONTROL 


ENGINEERING 

ADC 

CONTROL 


signal chain control 



FILTER wheel control 



FILTER wheel 
POSITION DATA 


STATE VECTOR 
DATA 



SERIAL NUMBER 
DATA 
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Cpalilco 

SOFTWARE STRUCTURE 


• REAL TIME INTERRUPT DRIVEN 

• FOREGROUND/BACKGROUND OPERATION 

• INTERNAL SPACECRAFT TIME CLOCK 

• TIME DISPATCHED EVENTS 

• SYNCHRONOUS OUTPUTS 


BASIC PROGRAM FLOW 
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APPLICATION OF MICROPROCESSORS TO 
INTERPLANETARY SPACECRAFT DATA SYSTEMS 

Samuel G. Deese 
Jet Propulsion Laboratory 
Pasadena, California 


The Jet Propulsion Laboratory has committed to the use of a microprocessor based 
distributed data system in the 1984 Galileo mission to Jupiter. There has been 
an evolution of this commitment following the advances in component and device 
technology. Early spacecraft were very simple with subsystems very much single 
function oriented. Our understanding was very high and the need for design and 
analysis tools very low. 

As technology grew, so did the complexities of the systems. Step by step, sub- 
systems and functions were combined thus increasing their capability as well as 
complexity. Missions became more ambitious and the returns were high. Costly 
design and analysis tools were developed to support system test and operations. 

With these tools we were able to some small degree analyze and/or predict the 
performance of the spacecraft. 

The Galileo Command and Data Subsystem (CDS) evolved from the combination of 
two special purpose computers from previous spacecraft: the Flight Data 

Subsystem and the Computer Command Subsystem. The CDS architecture utilizing 
concepts investigated in the development pf the Unified Data Subsystem (UDS) 
takes advantage of the microprocessor technology and serves as the core of the 
distributed microprocessors interconnected by a high speed data bus. 

The CDS design is complete and breadboard integration and test are in process. 

The flight software is in the requirements and "prototype" design phase. Many 
obstacles have been encountered and overcome. Some worthy of mention are: 

1) Choice of a microprocessor architecture based primarily on its 
power and radiation hardness qualifications. 

2) High speed operation of CMOS logic. 

3) Adaptation of a Higher order Language to a microprocessor and in 
particular to a processor with an architecture not well suited 
for the CDS application. 

4) The difficulties in obtaining quantities of qual ified parts that are 
very complex and have difficult requirements, i.,e. radiation hardening. 

5) Availability of design and analysis tools for understanding and 
validating distributed systems with concurrent processing. 

Ongoing advanced development and preproject studies are primarily based on data 
system designs having the same requirements as the CDS. We are committed in the 
future to the continued application of microprocessors to distributed data systems; 
solutions to the above problems; and to continue to follow advances in technology 
with the incorporation of VLSI into modular fault tolerant building blocks. 

In summary, technology and complexity have very rapidly advanced since the first 
Ranger spacecraft in the 1960s. The design and analysis tools have sadly lagged 
this progress leaving our ability to "best" design and understand what we have 
designed less than optimum. Along with our use of the new technologies of the 
future, we must also attack this deficiency. 
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THE CHRONOLOGICAL PATH 
TO MICRO-PROCESSOR APPLICATION 


MISSIONS: 

- LUNAR (RANGER) 

- MARS 


- VENUS 


- MERCURY 

- JUPITER 


CONTROL & DATA SYSTEMS; 


1960's 


M64 

V 

FLYBY 


Mb? 

V 

FLYBY 


I 1970' s 


M69 M71 VIKING 

V V V 

FLYBY ORBITER ORBITER & LANDER 

VMVM 

FLYBY 


1980' s 


FTS 

DAS 

FCS 

CC&S 


VMVM 


VGR GLL 

V V 

FLYBY ORBITER 


VlfOS U 


FDS 2 


>— CHl> 



CDS\ 


TECHNOLOGIES; 


CAPABILITIES: 


•DISCRETE COMPONENTS *10' s, MSI, LSI (TTL) 

•RANDOM LOGIC •PLATED WIRE 

•CORE mem; •SEMI COND. mem 


•LSI (CMOS) 

• fxP 

•SEMI COND. MEM. 


•HARDWIRED 

SEQUENCERS 


•PROGRAMMABLE 
SEQUENCERS 
(128 WORDS) 


•PARALLEL -DISTRIBUTED 

PROCEESORS SYSTEM 

(SEMI-DISTRIBUTED) (176 K MEM) 


TOOLS; 


•HAND CHECK 

•DETAILED 

•DETAILED SIMUI^TOR 

ASSEMBLER 


SIMUUTOR 

•ASSEMBLER & 

& SIMULATOR 


•ASSEMBLER 

MACROPROCESSOR 

•BREADBOARD 


THE BASELINE - UDS 

THE UDS. A DEVELOPMENT SPONSORED. BY THE NASA UNDER CONTRACT NAS7-100 
WITH THE CALIFORNIA INSTITUTE OF TECHNOLOGY AT JPL. 

SALIENT FEATURES,: 

- REAL TIME CONTROL - PRECISE TIMING 

- DISTRIBUTED ARCHITECTURE 

+ DISTRIBUTED FUNCT I ONS ( H I - LE VEL CONTROL. LOW-LEVEL EXECUTION). 
+ INTERACTION MINIMIZED 
+ HIERARCHICAL CONTROL 
+ COMPUTER INDEPENDENCE 

- STANDARDIZED SOFTWARE AND SUPPORT EQUIPMENT 

- STANDARD INTERFACES 
FEASIBILITY DEMONSTRATED VIA: 

- BREADBOARD OF BASIC SYSTEM UTILIZING NAKED MINI'S 

- ONE REMOTE TERMINAL UNIT (RTU) INCLUDING 8080 MICROPROCESSOR 

- DEVELOPED CONCEPT OF UDS DESIGN LANGUAGE (UOL) 

- DESIGNED AND .IMPLEMENTED "TYPICAL" APPLICATION SOFTWARE 

- EXPLORED CONCEPTS OF DEBUGGING A DISTRIBUTED SYSTEM 




THE UDS DESIGN 
(MARINER CLASS S/C) 



(ONE OF N) 


B1 B2 B3 PRIORITY ASSIGNMENT 



THE RTU 

INITIALLY DEVELOPED AS A PART OF THE UDS. 

- UDS I/O TYPE INTERFACES 

- UDS BUS INTERFACE 

- MICROPROCESSOR DRIVEN 

PROPOSED FOR DEVELOPMENT AS A NASA STANDARD FOR ^POSSIBLE USE WITH: 

- MMS (DHCS - NSSC-1 ) 

- GALILEO 

- VARIOUS PREPROJECT STUDIES 
CONCEPT DIED 

- BURDENED WITH UNIVERSAL I/O 

- SALE OF THE CONCEPT - NO VOLUNTARY FIRST USER 

- FEW SUPPORT FACILITIES . 

MAIN INHERITANCE FROM THIS EFFORT - RCA 1802 MICROPROCESSOR, 
IMPLEMENTATION CONCEPTS OF BA AND BC . 
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GALILEO 


A COMMITMENT TO A DI STRI BUTED DATA SYSTEM UTILIZING THE MICROPROCESSOR 
TECHNOLOGY IN A FLIGHT DEVELOPMENT ENVIRONMENT 

DRIVERS ON DEVELOPMENT 

- UDS AS A BASELINE 

■ - LOW POWER AND RADIATION DICTATE ACCEPTANCE OF THE RCA 1802 

- COMBINING FOS AND CCS INTO SINGLE SUBSYSTEM 

- CHEAPER OPERATIONS 

- VOYAGER AS A BASELINE 

- CMOS (4000 SERINES) SUPPORT LOGIC 

- MUST USE HOL (SPECIFICALLY, HAL-S) 

- NOTION THAT THE MORE YOU DO ON BOARD - THE CHEAPER ON GROUND 
STATUS 

- DESIGN COMPLETE (HARDWARE) 

- ARCHITECTURAL DESIGN OF FLIGHT SOFTWARE IN PROGRESS. SOME PROTOTYPE/ 
BREADBOARD DESIGNS. (J. THOMAS PRESENTATION) 

- BREADBOARD AND SUPPORT EQUIPMENT INTEGRATED DESIGN VERIFICATION IN PROCESS 

- HAL-S HAS BEEN REMOVED AS A REQUIREMENT. 

- DESIGNS FOR SOFTWARE AND OPERATIONS SUPPORT TOOLS IN PROGRESS. 


GALILEO DESIGN 



HIGH LEVEL MODULE 


LOW LEVEL MODULE 


BULK memory 













OTHER PROPOSED APPLICATIONS 


COMET RENDEZVOUS 

- MANY IMPLEMENTATIONS PROPOSED DEPEpiNG ON CHARACTER OF 
MISSION AT ANY GIVEN TIME AND ECONOMIC ENVIRONMENT. 

+ BASED ON "CORE” DISTRIBUTED DATA SYSTEM 
+ USERS NEED COMPUTING POWER 

+ COMPUTING POWER DERIVED AS A STANDARD FOR THE S/C AND 
• WOULD SIMPLY BE INCORPORATED INTO THE USER DESIGN 
{RTU SANS THE I/O) . 

OTHER PROPOSALS HAVE BEEN MADE, PRIMARILY BASED ON THE DISTRIBUTED 
SCHEME. 


COMET RENDEZVOUS PROPOSED DESIGN 


GND CMOS. SEP RF LINK 



ONE OP N 













THE CHRONOLOGICAL PATH OF PROBLEMS 

EARLY DESIGNS { M69 » M7 1 , M73 ) ' 

- SIMPLE OESIGMS EASILY UNDERSTOOD 

- COMPONENT COMPLEXITY LESS; EASILY TESTED AND SCREENED 
+ PROCESS PROBLEMS (PURPLE PLAGUE, CORROSION, ETC.) 

- HARDWARE AND SOFTWARE DESIGN AIDS A VAI LABL E E ARL Y 
+ DETAILED SIMULATOR 

• MEMORY SIZING 

• TIMING 

• TEST SOFTWARE DEVELOPMENT AND VALIDATION 
+ ASSEMBLER/LOADER 

- SIMPLER SOFTWARE (128/500 words) 

RECENT DESIGNS (VIKING, VOYAGER) 

- DESIGNS MORE COMPLEX 

- INCREASED COMPONENT COMPLEXITY 

- HARDWARE AND SOFTWARE DESIGN AIDS AVAILABLE EARLY 
+ -DETAILED SIMULATOR 

+ ASSEMBLER/MACRO PROCESSOR 


THE CHRONOLOGICAL PATH OF PROBLEMS (CONT.) 

RECENT DESIGNS (VIKING, VOYAGER) CONT. 

- INCREASED 'complexity IN SEQUENCING 

- ON-BOARD FAULT MANAGEMENT (LIMITED) 

- MORE COMPLEX SOFTWARE 

- DECREASING R&AD FUNDS 

GALILEO AND FORWARD 

- LACK OF EARLY DEVELOPMENT TOOLS 

- VERY COMPLEX COMPONENTS 

- INCREASED COMPLEXITY IN SEQUENCING, ON-BOARD FAULT MANAGEMENT 

- MORE SEVERE ENVIRONMENTS 

- LACK OF CONTINUITY OF MISSIONS 

- FURTHER DECREASE IN R&AD FUNDS 

- MUST BE CHEAP 

SPECIFIC PROBLEMS 

- DIFFICULTY IN APPLYING HOL (HAL-S) TO RCA 1802 

- RCA 1802 ARCHITECTURE PROBABLY NOT BEST SUITED FOR CDS TASK. 
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THE CHRONOLOGICAL PATH OF PROBLEMS (CONTJ 

SPECIFIC PROBLEMS (CONT. ) 

- RADIATION HARDENING PROBLEMS 

- ARCHITECTURAL EVALUATION 

• MEMORY SIZING 

• BUS TRAFFIC 

• TIMING MARGINS 

- DEVELOPMENT AND TEST OF TEST SOFTWARE 

- COMPETITION IN LABOR MARKET 
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THE ROLE OF THE MICROPROCESSOR IN ONBOARD 
IMAGE PROCESSING FOR THE INFORMATION ADAPTIVE SYSTEM 

W. Lane Kelly, IV, and Barry D. Meredith 
Langley Research Center 
Hampton, Virginia 

The Information Adaptive System (IAS) is an element of the NASA End-to- 
End Data System program and is focused toward high speed onboard data pro- 
cessing for NASA missions in the 1980' s. Particular emphasis is placed on 
multispectral-image data processing since the speed and quantity of that variety 
of data places the greatest burden on the current NASA data system. Some of the 
image processing functions planned for the IAS include sensor nonuniformity 
correction, geometric correction, data editing, formatting, packetization 
and adaptive system control. 

The design of the IAS is intended to apply to a variety of future missions; 
therefore, architectural flexibility is a key design feature. The programmability 
of the microprocessor lends this required flexibility to the system, allowing 
it to accommdate new processing functions and interface with a variety of sensor 
configurations. The high throughput rate required for mul ti spectral image data 
processing prohibits the use of conventional computer software approaches 
without significant increases in the speed of the central processing unit. Hence, 
a combination of high speed Special purpose hardware and microprocessors for 
control and computational support, appears to offer the best technical approach 
for the near term. In addition, a sophisticated microprocessor wil 1 serve as 
the overall system supervisor interfacing with commands from the spacecraft 
and the ground. 

This paper presents the preliminary design of the Information Adaptive System 
and discusses the role of the microprocessor in the implementation of the 
individual processing elements. 
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THE CURRENT NASA DATA SYSTEM PROBLEM 

• EVER INCREASING DEMAND MET WITH PROBLEM BY PROBLEM 
SOLUTIONS. 

• CURRENT DATA LOAD - 10" bits/day. 

• DATA PROCESSING DELAYS ARE EXCESSIVE. 

• DATA PROCESSING COSTS ARE TOO H IGH. 

• FORTHCOMING PROJECTS WILL INCREASE DATA LOAD BY AN 
ORDER OF MAGNITUDE. 

• SHUnLE CAPABILITY WILL BOOST LAUNCH RATE BY FACTOR 
OF 6. 


NEEDSfn -INFORMATION ADAPTIVE SYSTEM 

GOAL DES IGN, DEVELOP AND DEMONSTRATE IN EARLY 1983 
A SYSTEM ARCHITECTURE THAT UTILIZES ADVANCED 
TECHNOLOGY FOR HIGH-SPEED MULTISPECTRAL IMAGE 
DATA PROCESSING. 

DESIGN 

FEATURES: • HIGH DATA THROUGHPUT RATE 

• PROGRAMMABILITY 

• FLEXIBLE ARCHITECTURE 

• ADAPTABILITY 



IAS DEMONSTRATION SYSTEM BLOCK DIAGRAM 



STATAS/DATA 


RADIOMETRIC CORRECTION - LINEAR CURVE 
FIT APPROACH 


DIGITAL 

SENSOR 

INPUT 

DATA 
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LOOKUP TABLE DESIGN FOR RADIOMETRIC CALIBRATION 


input corrected 

SENSOR OUTPUT 



BUS BUS 


SOURCES OF DISTORTION IN IMAGE DATA AND THEIR 
CORRESPONDING ERROR MEASUREMENT TECHNIQUES 


EPHEMERIS VARIATIONS ►GLOBAL POS ITIONING SYSTEM (GPS) 

SPACECRAFT AHITUDE ^ADVANCED STAR TRACKER 

VARIATIONS 

SENSOR MISALIGNMENT ►PERIODIC GROUND CALIBRATION 

EARTH CURVATURE ►GPS WITH LOCAL EARTH RADIUS 

INFORMATION 
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GEOMETRIC CORRECTION 



GEOMETRIC CORRECTION PROCESSING 


RADIOMETRICALLY 

CORRECTED 

INPUT PIXELS : — 


SPECIAL PURPOSE RESAMPLING 
HARDWARE 

• APPLIES CUBIC CONVOLUTION 
ALGORITHM TO INPUT PIXELS 

• PERFORMS ALONG TRACK AND 
ACROSS TRACK RESAMPLING 


UNDISTORTED 
OUTPUT PIXELS 


CONTROL 


DISTORTION 

PARAMETERS 


FROM I 

Asc r 


AHITUDE 


EPHEMERIS 


LOCAL RADIUS 


SOPHISTICATED GENERAL PURPOSE PROCESSOR 


• PERFORMS COORDINATE TRANSFORMATIONS 

• SUPPLIES DISTORTION PARAMETERS 

• CONTROLS RESAMPLING HARDWARE 


ALIGNMENT 
ERROR — 





EDITING CRITERIA UNDER INVESTIGATION 

FOR THE IAS 

• TIME 

• SPACECRAFT POSITION 

• INFORMATION FROM OTHER EXPERIMENTS 

• CLOUD COVER 


IMPLEMENTATION OF CLOUD DETECTION ALGORITHM 
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BUFFER MEMORY SYSTEM FOR DATA FORMATTING 


INPUT 

DATA 



FORMAHED 

OUTPUT 

DATA 


NASA DATA PACKET FORMAT 


1 PRIMARY 1 

SECONDARY 

1 SOURCE 

1 PACKET 1 

1“ HEADER ~T 

~ HEADER “ 

1 DATA 

"TPARITY~1 


SOURCE I.D. 
MISSION I. D. 
PACKET LENGTH 
ETC. 


— i J 

ANCILLARY DATA; 
TIME, SPACECRAFT 
POSITION AND AHITUDE 
ETC. 




— ( f 

VARIABLE 
LENGTH PROCESSED 
DATA 


-( f 


ERROR 

CODES 
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HIGH SPEED PING-PONG MEMORY APPROACH TO DATA 


PROCESSED 

DATA 

INPUT 



PACKETIZED 

DATA 


ADAPTIVE SYSTEM CONTROLLER TASKS 

• INITIALIZE INDIVIDUAL CONTROLLERS 

• ASSIST CONTROLLERS IN INITIALIZATION OF IAS COMPONENTS 

• ESTABLISH AND MAINTAIN OPERATING MODE 

• MONITOR STATUS OF ALL IAS COMPONENTS 

• FORMULATE ERROR MESSAGES 

• MAINTAIN COMMUNICATION WITH SPACECRAFT AND GROUND 

• PROVIDE COMPUTATIONAL SUPPORT TO IAS MODULES 
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ADAPTIVE SYSTEM CONTROLLER DESIGN 

FEATURES 

• SOPHISTICATED MICROPROCESSOR ARCHITECTURE 

• ADAPTABLE 

• EXPANDABLE 

• COMPATABLE WITH HIGH ORDER LANGUAGE 
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APPLICATION OF A MICROPROCESSOR TO A 
SPACECRAFT ATTITUDE CONTROL 

D. H. Brady and F. W. Hermann 
TRW Defense and Space Systems Group 
Redondo Beach, California 

The space-qualified TDRSS attitude control system (ACS) microprocessor 
development work spanned three main design areas: hardware and instruction set, 
ACS firmware, and hardware/firmware verification testing. 

The Control Processor Electronics (CPE) hardware utilizes two parallel 
AM2901 4-bit microprocessors, with a microprogrammed instruction set tailored 
to the TDRSS controls application. Fourteen special purpose I/O instructions 
interface with the ACS hardware, each transferring data for one sensor while 
meeting timing and data-handl ing requirements. The ACS firmware resides in 
5120 bytes of ROM with 1024 bytes of RAM for scratch data storage. The 16-bit 
add, subtract, and divide operations are overflow-protected and multiplies are 
done in hardware. 

The firmware includes data processing for five sensors, four attitude 
control laws, and telemetry and commands. The main design limitations were: 
16-bit word length, 1024 8-bit byte RAM, and computation speed/task sharing 
tradeoffs. It performed ACS computations quickly and without significant data 
degradation. The word length limitation motivated the careful selection of 
control filter topology and sacrifice of dynamic range in favor of null per- 
formance. 

The flight program design was tested with three tools: Varian V-73 mini- 
computer, CDC Cyber computer, and the CPE development station. The V-73 
simulation tested source (assembly) programs prior to development station 
availability. The CDC Cyber simulation was used primarily for accuracy 
analysis. The development station included commercial versions of the flight 
hardware which were run at full speed. All formal verification tests were 
run on the development station to verify timing, accuracy, and interface re- 
quirements. 

From this development experience, additional hardware and software re- 
quirements were identified: 

0 Rapid Memory Examine/Change 
0 Floating point hardware 
0 High level language 
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ANALOG 

AND 

SERIAL - 
DIGITAL 1 
SENSOR - 
DATA 


TDRSS ATTITUDE CONTROL HARDWARE 


TRW 


• CONTROL ELECTRONICS ASSEMBLY 

• SENSORS 

- EARTH SENSOR 

- COARSE SUN SENSORS 

- FINE SUN SENSORS 

- GYROS 

- REACTION WHEEL TACHOMETERS 

- SOLAR ARRAY DRIVE RESOLVERS 

• ACTUATORS 

- THRUSTERS 

- REACTION WHEELS 


TDRSS CONTROL ELECTRONICS ASSEMBLY 


TRW 




SERIAL SERIAL 
COMMANDS TELEMETRY 
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CPE BLOCK DIAGRAM 
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► STROBE STROBE 


CPE INSTRUCTION SET 

T/tur 




• SPECIFIED BY CPE CONTROL FIRMWARE DESIGNERS TO BE OPTIMUM FOR 

TDRSS APPLICATION 

• INSTRUCTION SET MICROPROGRAMMED BY HARDWARE DESIGNERS 

• 108 TOTAL INSTRUCTIONS INCLUDING: 

- SINGLE- OR MULTIPLE-BIT. SET, RESET AND TEST . 

- 16-BIT FRACTIONAL FIXED-POINT ARITHMETIC 

- 16-BIT ADD, SUBTRACT AND DIVIDE CLAMPED AT ±1.0 WHEN 
OVERFLOW OCCURS 

- MULTI-BIT LOGICAL AND ARITHMETIC SHIFTS (SINGLE AND 
DOUBLE-PRECISION) 

- FOURTEEN INPUT/OUTPUT INSTRUCTIONS DEDICATED TO PARTICULAR 
SENSORS OR ACTUATORS WITH ALL HARDWARE TIMING BEING TAKEN 
CARE OF IN THE MICROCODE. FOR EXAMPLE, INSS INSTRUCTION 
INPUTS ALL DATA ASSOCIATED WITH THE COARSE AND FINE SUN 
SENSORS TO PAGE 0 OF RAM; OUWTQ OUTPUTS TORQUE COMMANDS TO 
THE REACTION WHEELS FROM PAGE 0 OF RAM. 
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PROGRAM STRUCTURE 


TRW 


START 
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TELEMETRY FORMATTING AND PROCESSING 
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QYRO PROCESSING 
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INERTIAL MODE CONTROL LAW PROCESSING 
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NORMAL MODE CONTROL LAW PROCESSING 


0.20 SEC 

SUN MODE CONTROL LAW PROCESSING 
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RWA CONTROL LAW PROCESSING 
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VOE OUTPUT PROCESSING 



*TELEMETNY BIT RATES OF 2B0, 1000, AND 4000 BITS/SECONO ARE SELECTABLE 
FOR THE 512 BIT MAIN FRAME. THESE PRODUCE TELEMETRY CYCLE TIMES OF 
2.048. 0.512, AND 0.128 SECONDS RESPECTIVELY. 

''execution frequency (NOT EXECUTION TIME) FOR EACH PROGRAM MODULE. 


FIRMWARE DEVELOPMENT/VERIFICATION PHILOSOPHIES 


TRtlV_ 


DESIGN SCOPE - 

t MICROPROCESSOR DEDICATED TO ATTITUDE CONTROL FUNCTION 

• INSTRUCTION SET TAILORED TO CONTROL NEEDS (ARITHMETIC 
LIMITING, CONTROL HARDWARE I/O) 

DESIGN PERSONNEL 

• FIRMWARE DESIGNED CODED, AND TESTED BY CONTROL SYSTEMS 
ENGINEERS 

- IMPROVED COMMUNICATION FOR MECHANIZATION OF CONTROLS 
REQUIREMENTS IN FIRMWARE 

- INTERACTION IMPROVED FOR ACHIEVING ADEQUATE PERFORMANCE 
IN THE FIRMWARE 

INDEPENDENT VERIFICATION 

• ACHIEVED BY SWAPPING MODULE RESPONSIBILITY AT VERIFICATION 
TIME 

• VERIFICATION TEST PLAN INDEPENDENT OF MODULE DESIGNERS 

• REVIEW OF TEST RESULTS BY CONTROL LOOP ANALYSTS 
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CONSTRAINTS AND THEIR EFFECTS ON FIRMWARE DESIGN 


TRW 


16 BIT WORD LENGTH MAXIMUM, 8-BIT BYTES 

t CAREFUL MAGNITUDE SCALING FOR COMPUTATIONS 

• QUANTIZATION EFFECTS ON CONTROL FILTER TOPOLOGIES 

• LOW LEVEL PERFORMANCE/DYNAMIC RANGE TRADEOFFS . 

102A 8-BIT BYTES ADDRESSABLE IN RAM 

• ATTITUDE CONTROL FILTER COMPLEXITY 

• FILTER STATE ACCURACY/MULTIPLE PRECISION ARITHMETIC 

DATA PROCESSING 

t COMPUTATION COMPLEXITY/TIME DELAYS 
t COMPUTATION COMPLEXITY/TASK SHARING 


FILTER IMPLEMENTATION TOPOLOGIES 


TRW 


WORD LENGTH EFFECTS - 

• ACCURACY, QUANTIZATION 

FILTER TOPOLOGIES - 

• POLYNOMIAL FORM (REJECTED) 

• CASCADED FORM (ACCEPTED) 

OTHER ALTERNATIVE FORMS 

• PARALLEL FORM 

• MATRIX FORM 

• DFT, FFT 

SCALING CONSIDERATIONS 

• TOPOLOGY AND GAIN DISTRIBUTION FOR 
INTERMEDIATE STATES 

DYNAMIC RANGE, ETC. 


t 



FIRWARE ttVELOPMENT s VERIFICATION TOOLS 


TRW 

mmmwmtaww%Tmmwmm 


• VARIAN V-73 niNICOMPUTER 

• 8 AND 16 BIT ARITHMETIC 

t FORTRAN FUNCTIONS SIMULATING INDIVIDUAL CPE INSTRUCTIONS 

• PROVIDES INTERFACE IN ENGINEERING UNITS FOR MAXIMUM 
VISIBILITY 

, t INPUT SAME AS ASSEMBLER INPUT 

• CYBER 7A TIMESHARE 

• SCIENTIFIC SIMULATION OF ARITHMETIC INSTRUCTIONS 

• PROVIDES TOOL FOR CONTROL LOOP DESIGNERS 

- .'.ASSESS LIMITED WORD LENGTH EFFECTS 

- FILTER DESIGN . 

• RESIDENCE FOR CONTROLLED CPE SOURCE PROGRAM 

• RESIDENCE FOR CPE ASSEMBLER PROGRAM 


FIRMWARE DEVELOPMENT 


VERIFICATION TOOLS (CONTINUED) 


TRW_ 


• TI 990/10 MINICOMPUTER 

• VERIFICATION TOOL 

• USED AS DRIVER FOR VERIFICATION TESTS 

• DATA COLLECTION AND PRINTOUT 

• PROVIDES DYNAMICS SIMULATION FOR DYNAMIC ENVIRONMENT 

• CPE DEVELOPMENT STATION 

• BREADBOARD CPE 

• FRONT PANEL FOR PROGRAM ENTRY, EDIT, AND EXECUTION 

• INTERFACE BOX 

• HARDWARE LINK OF TI 990/10 AND BREADBOARD CPE 

• GROUND STATION COMMAND SIMULATOR 
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DEVELOPMENT STATION EQUI PMENT 
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TF 990/10 AND PROM PROGRAMMER INTERFACE BOX AND CONTROL 

PROCESSOR DEVELOPMENT STATION 






REVIEWING THE FIRnWARE DESIGN 


TRW 


DESIGN IMPROVEMENT, FUTURE DESIGNS ARE ENHANCED BY DESIGN REVIEW AT SIGNIFICANT 
MILESTONES - 


• INITIAL DESIGN 

• COARSE PROGRAM FLOWS 

• DETAILED PROGRAM FLOWS 

• CODE CHECKOUT, MODULE LEVEL 

DESIGN REVIEW AREAS - 

• HARDWARE DESIGN 

• MICROCODE DESIGN 

• INSTRUCTION SET DESIGN 

• GROUND STATION COMMANDS SET 


t TOTAL INTEGRATED PROGRAM VERIFICATION 

• SUBSYSTEM TESTING 

• SPACECRAFT OPERATIONS DESIGN 

• FLIGHT EXPERIENCE 


• TELEMETRY DATA AVAILABLE 

• PROGRAM STRUCTURE 

• DESIGN PHILOSOPHIES 


REVIEWING THE FIRMWARE DESIGN 


trw_ 


SOME DESIGN IMPROVEMENTS UNCOVERED - 

• RAM MEMORY LOAD AND MOVE DATA INSTRUCTION 

• EXECUTIVE PROGRAM AND SUBROUTINES STRUCTURE 

• GROUND COMMANDS TAILORED TO SPACECRAFT OPERATIONS 

• MICROPROCESSOR DEVELOPMENT STATION SOFTWARE CHECKOUT 
FEATURES 

- RAM 

- SCRATCHPAD VISIBILITY 

- RAPID MEMORY EXAMINE/CHANGE 

• CONTROL FILTER STATES WORD LENGTH s 2H BITS 

• FLOATING POINT HARDWARE 
t HIGH LEVEL LANGUAGE 


55 



Page Intentionally Left Blank 



8 


A PLASMA WAVE FOURIER TRANSFORM PROCESSOR EMPLOYING 1802 
MICROCOMPUTERS FOR SPACECRAFT INSTRUMENTATION 

Donald C. Lokerson and James N. Caldwell 
Goddard Space Flight Center 
Greenbelt, Maryland 

The requirements of low power, small space, low weight, and high data compression limit the 
capabilities of interplanetary plasma wave processing. The processing of plasma wave signals in 
spinning spacecraft in the range from D.C. to 500Hz are described. Another signal source from 
the intermediate frequency of a sounder transponder is processed by the same hardware, but with 
linear Fourier transform software. 

Three antenna inputs are filtered to prevent aliasing above 500Hz. A 92 db range of data is 
multiplexed to an analog-to~digital converter, and then to three RCA 1802 microcomputers. 
Groups of this data are collected under DMA control by each microcomputer. A logarithmically- 
spaced Fourier transform is computed. Each computer requires 2 kilowords of read-only-memory 
and a half kiloword of random access memory. 

Data at lower frequencies is spin modulated by the spacecraft. For these signals, data is 
sampled 512 times in one spin and also processed by logarithmically-spaced Fourier transform 
techniques. A fourth microcomputer . performs this task and coordinates all operations. This 
microcomputer requires 5 kilowords of read-only-memory and 3.5 kilowords of random address 
memory. The computer also performs data averaging, peak detection, data formatting, output 
compression, and ground commanded tasks. 
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INPUT 


STATE 0 

• GAIN RANGE ALL INPUT GROUPS 

• STROBE ALL SAMPLE AND HOLD AMPLIFIERS 

STATE 1 

• A/D CONVERT S/H NO. 1 

• DMA GAIN RANGE AND A/D DATA FOR GROUP NO. 1 TO MICRO NO. 1 


STATE 2 

• /VD CONVERT S/H NO. 2 

• DMA GAIN RANGE AND A/D DATA FOR GROUP NO. 2 TO MICRO NO. 2 


STATE 3 

• A/D CONVERT S/H NO. 3 

• DMA GAIN RANGE AND A/O DATA FOR GROUP MO. 3 TO MICRO NO. 3 


GROUP 
NO. 1 


GROUP 
NO. 2 


GROUP 
NO. 3 
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PROTOTYPE DEVELOPMENT OF A MICROPROCESSOR-BASED 
ONBOARD ORBIT DETERMINATION SYSTEM 

Keiji K. Tasaki and Rose S. Pajerski 
Goddard Space Flight Center 
Greenbelt, Maryland 


DEVELOPMENT STAGES OF ONBOARD 
ORBIT DETERMINATION SYSTEMS 


[operational! 

,_SYSTEMS_| 


FLIGHT EXPERIMENT SYSTEM 


• WILL USE MOST ADVANCED FLIGHT- 
QUALIFIED PROCESSOR 

• WILL PROCESS MEASUREMENTS MADE 
ONBOARD 

• WILL HAVE SUPPORT EQUIPMENT 


PROTOTYPE SYSTEM 


• USES PDP-11 /23 

• OPERATES IN A SIMULATED ENVIRONMENT 

• PROCESSES REAL OR SIMULATED DATA 


DEMONSTRATION SYSTEM 


• USED IMP-1 6 S 

• PERFORMED COMPLEX MATH FUNCTIONS 

• DEMONSTRATED FEASIBILITY 


1978 


1980 


1982 


1984 


TIME 


OBJECTIVES 


1 . DEVELOP A MICROPROCESSOR-BASED AUTOMATED ORBIT 
DETERMINATION SYSTEM (AODS) USING: 

• PDP-1 1/70 AS THE DEVELOPMENT MACHINE 
9 PDP-11 /23 AS THE TARGET MACHINE 

• HIGH-LEVEL LANGUAGE - FORTRAN 

2. EXERCISE THE SYSTEM IN CONJUNCTION WITH A SIMULATOR. 

3. REFINE SOFTWARE TO ACHIEVE HIGHER EFFICIENCY. 
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SOFTWARE OVERVIEW 
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FLIGHT EXPERIMENT CONFIGURATION 


TO ANTENNA 



FLIGHT EXPERIMENT CONSIDERATIONS 


1. SELECTION OF A FLIGHT-QUALIFIED PROCESSOR 

• 64-BIT FLOATING POINT ARITHMETIC 

• LARGE ADDRESSABLE MEMORY (BEYOND 64K) 

• MULTITASKING OPERATING SYSTEM 

2. HARDWARE INTERFACE 

• RECEIVER - ADDS - COMMAND AND DATA MODULE 

• AODS - OTHER ONBOARD PROCESSORS 




SESSION II 


GROUND BASED AEROSPACE 
MICROPROCESSOR APPLICATIONS 



10 


THE REMOTE COMPUTER CONTROL (RCC) SYSTEM 

William Holmes 
Goddard Space Flight Center 
Greenbelt, Maryland 


A system to remotely control job flow on a host 
computer from any touchtone telephone is currently being 
developed at Goddard Space Flight Center (GSFC) . Using this 
system a computer programmer can submit jobs to a host 
computer from any touchtone telephone. In addition the 
system can be instructed by the user to call back v/hen a job 
is finished. Because of this system every touchtone 
telephone becomes a conversant computer peripheral. This 
system known as the Remote Computer Control (RCC) system 
utilizes touchtone input, touchtone output, voice input, and 
voice output. The RCC system is microprocessor based and is 
currently using the INTEL 80/30 microcomputer. Using the 
RCC system a user can submit, cancel, and check the status 
of jobs on a host computer. A user can also have the RCC 
system call when a specified condition is fulfilled. For 
example, a user could have the RCC call when a specific job 
has been successfully completed on a host computer. 


The peripherals used for communication with the user 
over the telephone are the MH88205 DTMF Receiver/Decoder by 
Mitel for touchtone input, the MC14410P integrated circuit 
by Motorola for touchtone output, the Voice Recognition 
Module (VRM) by Interstate Electronics for voice input and 
the ML-I Multi-Lingual Voice System by Federal Screw Works 
for voice output. The RCC system peripherals consist of a 
CRT for operator control, a printer for logging all 
activity, mass storage for the storage of user parameters, 
and a PROM card for program storage. 


This RCC system enables a user to communicate v/ith a 


a host computer from 
The use of this system 
a host computer by 


host computer and control job flow on 
any touchtone telephone at any time, 
can decrease turnaround time on 
minimizing the time between job 
notification of job termination, 
distribute the work load of a host computer to off 
enabling a user to control the host computer job 
any remote touchtone telephone. 


term mat ion 
This system 


and user 
can help 
hours by 
flow from 
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A MICROPROCESSOR APPLICATION TO A STRAPDOWN LASER GYRO NAVIGATOR 

C. Giardina and E. Luxford 
The Singer Company-Kearfott Division 
Little Falls, New Jersey 

This paper is concerned with replacing analog circuit control loops 
for laser gyros (path length control, cross axis temperature compensa- 
tion loops, dither servo and current regulators), with digital filters 

residing in microcomputers. The object of using this type of design 
is to improve on system reliability (through part count reduction) , 
reduce size and power requirements, and therefore, improve on system 
performance. Consistent replication in the design is a further 
benefit derived by replacing analog components with digital software. 

In addition to the control loops, a discussion will be given on 
applying the microprocessor hardware to compensation for coning and 
skulling motion where simple algorithms are processed at high speeds 
to compensate component output data (digital pulses) for linear and 
angular vibration motions. 

Highlights are given on the methodology and system approaches used 
in replacing differential equations describing the analog system 
in terras of the mechanized difference equations of the microprocessor. 
Here standard one for one frequency domain techniques are employed 
in replacing analog transfer functions by their transform counterparts 
Direct digital design techniques are also discussed along with their 
associated benefits. Time and memory loading analyses are also sum- 
marized, as well as signal and microprocessor architecture utilized 
to do the "best job" . 

Trade offs in algorithm, mechanization, time/memory loading, 
accuracy and microprocessor architecture are also given. 
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RLG CONTROL LOOPS - PERFORMANCE INFORMATION 


Loop 

Purpose of Loop 

Method of Improving Performance 

Required Control | 

Loop Bandwidth j 

Dither 

Eliminate damping in 
dither spring mecha- 
nism 

Overcome backscattered light between 
two beams due to mirror (reflector) 
imperfections and thereby circumvent 
lock-in 

Moderate when compared 
to microcomputer speeds 

Current 

Regulator 

Balance anode currents 

Minimize drift due to gas flow in 
laser cavity 

Long when compared to 
microcomputer speeds 

Path Length 
Control 

Maintain path length 
in cavity at an in- 
tegral number of 
wave lengths 

Minimize drift due to temperature 
variation of block 

Long when compared to 
microcomputer speeds 

\ 

BBMM 

Center beam in cavity 

Minimize drift due to temperature 
variation of block 

Long when compared to 
microcomputer speeds 

Variable 
Beam Inten- 
sity Corrector 

Locate mirrors to 
minimize total back- 
scatter "vector” from 
the three mirrors 
(thereby reducing 
effective lock-in 
level) 

Minimize output random noise 
. resulting from dither 

Long when compared to 
microcomputer speeds 

t 


RLG CONTROL LOOPS - OBSERVABLES AND METHOD OF CONTROL COMPARISON 


Loop 

Observed Signal 

Control Signal 

Method of Obser 
Analog 

ving Signal 
Digital 

Dither 

Dither Amplitude 

Force applied to gyro 
dither spring through 
voltage applied to PZT 
device 

Full wave recti- 
fied dither ampli- 
tude 

Measurement of 
peak dither ampli- 
tude through succes- 
sive measurement of 
amplitude 

Current 

Regulator 

Difference in anode 
currents 

Base voltage applied 
to control transistor 

Output voltage 
from difference 
amplifier repre- 
senting difference 
current 

Same as analog 

Path Length 
Control 

Beam intensity 

Force applied to 
movable mirror 
through voltage 
applied to PZT device 

Rectification of a 
carrier signal mod- 
ulating beam inten- 
sity 

Measurement of beam 
intensity variation 
with path length 
variation through 
successive iterations 
of path length 

Cross Axis 

Temperature 

Compensator 

Beam Intensity 

Force applied to gyro 
block through voltage 
applied to PZT device 

Rectification of a 
carrier signal mod- 
ulating beam inten- 
sity 

1 

Measurement of beam 
intensity variation 
with force applied to 
the block through suc- 
cessive iterations of 
that applied force 

Variable 

Beam 

Itensity 

Corrector 

1 

! 

Variation in beam 
intensity (distor- 
tion) as gyro period- 
ically locks in during 
dither reversals. 
Variation usually 
occurs only with a 
given gyro turn-on , 

Force applied to a 
set of two movable 
mirrors through 
voltages applied to 
PZT devices 
■ 

Rectification of a 
carrier signal mod- 
ulating "winking" 
amplitude 

Measurement of "wink- 
ing" signal through 
successive iterations 
of position of two 
movable mirrors. The 
signal amplitude will 
be determined through 
direct integration. 
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THE SPACELAB EXPERIMENT INTERFACE DEVICE (SEID) 

Ron Kallus and Saul Stantent 
Intermetrics 

Cambridge, Massachusettes 

The Spacelab Experiment Interface Device (SEID) has been designed and 
built to simulate the spacelab. CDMS/RAU Interface for spacelab experiments. 

Its purpose is to provide a low cost method to aid in experiment hardware/ 
software verification and spacelab/experiment interface verification. 

Until recently a spacelab experimenter would have to set aside time and 
resources for the design and construction of a suitable interface simulator. 

Any incompatibilities discovered during spacelab integration could result in 
the removal of the experiment from the flight. The consequences of integration 
failure may substantially increase project cost and create unacceptable project 
delay. 

The SEID simulates the electrical, and logical connections of the Spacelab 
Remote Acquisition Unit (RAU), the interface functions of the spacelab experiment 
computer software, and the electrical aspects of the High Rate Multiplexer 
(HRM). . 

The SEID meets ESA and NASA electrical, level, timing, drive, and loading 
requirements for the RAU and HRM interface. Simulated RAU interfaces include 
PCM serial channels (up to four). User Time Clock (UTC), flexible inputs (uo 
to 128) and descrete outputs (up to 64). Connectors are logically compatible 
with the RAU. 

The SEID accepts commands from any ASCII source, to execute RAU functions 
which are normally driven from the software resident in the central experiment 
computer. The commands are entered in a symbolic or a compressed format and 
can be executed singly or in user defined groups. 
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The experiment can thus be connected to the SEID, subjected to various 
sequences of operations and checked for proper system interface characteristics. 

The SEID can be instructed to execute sequences of input/output commands 
to the RAU, similar to those performed during flight. This approximation 
of the experiment computer software is adequate to detect interface problems 
and prevent these from occurring during Spacelab--Payload integration. 

The SEID hardware is a microprocessor based system, utilizing an 8085 micro- 
processor with 6K of PROM and 4K of static RAM. 
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SUMMARY 


The Spacelab Experiment Interface Device (SEID) has been designed and 
built to simulate the spacelab. CDMS/RAU Interface for spacelab experiments. 

Its purpose is to provide a low cost method to aid in experiment hardware/ 
software verification and spacelab/experiment interface verification. 

Until recently a spacelab experimenter would have to set aside time and 
resources for the design and construction of a suitable interface simulator. 

Any incompatibilities discovered during spacelab integration could result in 
the removal of the experiment from the flight. The consequences of integration 
failure may substantially increase project cost and create unacceptable project 
delay. 

The SEID simulates the electrical, and logical connections of the Spacelab 
Remote Acquisition Unit (RAU), the interface functions of the spacelab experiment 
computer software, and the electrical aspects of the High Rate Multiplexer 
(HRM). 


The SEID meets ESA and NASA electrical, level, timing, drive, and loading 
requirements for the RAU and HRM interface. Simulated RAU interfaces include 
PCM serial channels (up to four). User Time Clock (UTC), flexible inputs (uo 
to 128) and discrete outputs (up to 64). Connectors are logically compatible 
with the RAU. 

The SEID accepts commands from any ASCII source, to execute RAU functions 
which are normally driven from the software resident in the central experiment 
computer. The commands are entered in a symbolic or a compressed format and 
can be executed singly or in user defined groups. 
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The experiment can thus be connected to the SEID, subjected to various 
sequences of operations and checked for proper system interface characteristics. 

The SEID can be instructed to execute sequences of input/output commands 
to the RAU, similar to those performed during flight. This approximation 
of the experiment computer software is adequate to detect interface problems 
and prevent these from occurring during Spacelab — Payload integration. 

The SEID hardware is a microprocessor based system, utilizing an 8085 micro- 
processor with 6K of PROM and 4K of static RAM. The basic unit has been 
augmented with an LSI-11 microcomputer to provide disk storage and a more 
dynamic environment for generation of control data. A simulation of the 
General Monitor Loop (GML) is provided to emulate spacelab system timing. 
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Spacelab 

Experiment 

Interface 

Device 


<FOR PAYLOAD DEVELOPMENT^ 



SEID 
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mrivATioN 


• THE PRIHCIPAL INVESTIGATOR IS TOTALLY RFSPONSIBIF FOR THE CORRECT 
OPERATION OF HIS EXPERIMENT. 

» THE EXPERIMENT MUST HAVE BEEN TESTED PR I O'! TO LEVEL IV 
INTEGRATION. 

• HARDWARE/SOFTWARE ERRORS OCCURRING DURING PAYLOAD INTEGRATION 
MAY RESULT IN REMOVAL OF EXPERIMENT. 

• LEVEL IV INTEGRATION FACILITY (OR SIMILAR FACILITY) WILL NOT 
BE AVAILABLE FOR INDIVIDUAL EXPERIMENT TESTING/VERI FI CATION. 


SEID OBJECTIVES 

• TESTING OF EXPERIMENT HARDWARE . 

• TESTING OF EXPERIMENT PROCESSOR SOFTWARE . 

• TESTING OF SPACELAB/EXPERIMENT INTERFACE . 

• OFF-LINE TROUBLE-SHOOTING DURING PAYLOAD INTEGRATION. 

• INTERFACE CIRCUITS IDENTICAL (OR FUNCTIONALLY IDENTICAL) TO 
SPACELAB SPECIFICATIONS. 

• ALL INTERFACE CONNECTORS FUNCTIONALLY COMPATIBLE TO SPACELAB 
HARDWARE. 

• ABILITY TO APPROXIMATE ECOS/EAS SEQUENCES OF I/O OPERATIONS. 
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SPACELAB CONFIGURATION 


Mim 125 



USER Time clock channels 
64 Discrete ON/OFF commands 
4 Serial PCM CMO channels 

4 Serial PCM DATA channels 
128 Flex, inputs 


SPACELAB ENVIRONMENT j USER EXPERIMENT ENVIRONMENT 


SEID CONFIGURATION 



SEID 


USER 

SUPPLIED 
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SEID OPERATION MODES 


EQUIPMENT INTERFACE TESTING 
SEQUENCING 

DYNAMIC REAL TIME CONTROL 



EQUIPMENT INTERFACE TESTING 


STIMULUS: SEND DIGITAL PATTERN 
TO SELECTED CHANNEL 2 

00 

o 



7 




Examples of Commands; 

>ISSUE012, ON) 

>SENSE1608> 

>RZm2j 
> WRITE 0, 2, 1A3F, BOOJ 





SEQUENCING 


CRT OR TTY SEID EXRtRIMENT 



• User may specify sequences via keyboard 

• The sequence can form a loop and generate stimuli and 
buffer responses for CRT or TTY presentation 

• No external support software requi red 


Example: ENTERING A SEQUENCE 

> DEFINE 

seq 10 begun (echoed from 
= ISSUEt«7,0Nj 
= WAIT 3,0^^ 

= READ|62y 
= SENSEIilSy 

= ENDDEFs 

> START161? 

> STOP01^ 



SEID) 
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DYNAMIC REAL-TIME CONTROL 



In those situations where even more computer power may be necessary the SEID can be 

2 

interfaced to a user (or I -) supplied computer. This configuration enables the 
use of a GML simulation. 

Example: 

MONITOR ON 
LOAD TEST 
PERFORM TEST 
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SEID COMMANDS 


m 

' ISSUE nn.ON (OFF) 

PULSE nn.ON (OFF) 

SENSE NNN 
SAMPLE NNN 

WRITE N^CC^HHHH.HHHHyH 

DBL-WRITE NyCLc2yHHHH^HHHH- 
READ N 

SET-6MT DDDyMMMMMMMM 
SET-MET DDDyMMMMMMMM 
WRITE N GMT 
TIME 


SEQUENCE 

DEFINE 
ENDDEF 
START NNNN 
STOP NNNN 
WAIT SS<,MM 
- TYPE AAA— 


DEP 
LINK N 

DEP-RESP NyCCvHHHHHHHH- — 
DEP-WRITE ss,MM 
POLL- RATE ss.MM 
POLL-n 


SESME 
SPSME N 

SISSUE nn.ON (OFF) . 
SSENSE nn.nn.— 
SSAM-BLK NN^NN,— 
SSAMPLE NN 


LSI -11 COMMANDS 


I/O MONITOR 

MONITOR ON (OFF) 
ASSIGN ii.NN 
END 

REMOVE ii.NN 

SEQUENCE EDITING 

INSERT NN 
END 

DELETE NN 
CHANGE NN 


SEQUENCE MANIPULATION 

DEVELOP 

END 

SAVE NAME . 

DESPLAY NN>MM 

SEQUENCE EXECUTION 
LOAD NAME 

PERFORM NAME 



CONFIGURATION OPTIONS 



LSI 11/2 Front-End Controller Hardware 























FUTURE USES 

QFJTHE 

$EU) CONCEPT 


SHUTTLE PAYLOAD INTERFACE DEVICE: 

- PAYLOAD MDM 

- pcmu 

- MTU 

MORE GENERALIZED TEST EQUIPMENT: 

- ANALOG. SERIAL. DISCRETE INTERFACE CIRCUITS 
AS APPROPRIATE 
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G-CUEING MICROCONTROLLER 
(A MICROPROCESSOR APPLICATION IN SIMULATORS) 

Chris G. Horattas 
Goodyear Aerospace Corporation 
Akron, Ohio 


Digital Simulation of aircraft flight requires the iterative solution of a time 
and event dependent mathematical model. Simulation realism is enhanced by high 
rate of solution, A simulation whose solution rate produces cues which are per- 
ceived to be the same as real-world cues, is considered a real-time simulation. 
Achieving real time simulation is a prime consideration in simulator design. 

The computation system required to produce real-time simulation is either a 
single, high cost, extremely high speed processor, or an array of less powerful 
processors which share the computation task. When multiple processors are used 
in such array, each is usually dedicated to a simulation subtask and must oper- 
ate synchronously with the other processors in the array. 

One such dedicated processor is the G-Cueing Microcontroller (G-CM) . The G-CM 
consists of a tandem pair of microprocessors, dedicated to the task of simula- 
ting pilot sensed cues caused by gravity effects. This task includes execution 
of a g-cueing model which drives actuators that alter the configuration of the 
pilot's seat. 

The G-Cueing Microcontroller receives acceleration commands from the aerodynam- 
ics model in the main computer and creates the stimuli that produce physical 
acceleration effects of the aircraft seat on the pilots anatomy. One of the 
two microprocessors is a fixed instruction processor that performs all control 
and interface functions. The other, a specially designed bipolar bit-slice 
microprocessor with on-board hardware multiply and firmware implemented divide 
square root and sine functions, is a microprogrammable processor dedicated to 
all arithmetic operations. The two processors communicate with each other by 
a shared memory. 

The G-Cueing Microcontroller contains its own dedicated I/O conve-rsion modules 
(analog- to-digital , and digital-to-analog) for interface with the seat actuators 
and controls, and a DMA controller for interfacing with the simulation computer. 

Even though the microcontroller is programmed to perform the g-cueing model, it 
is not limited to this specific application. Any application which can be micro- 
coded within the available memory, the available real time and the available I/O 
channels, could be implemented in the same controller. Furthermore, the micro- 
controller capacity can be expanded by the addition of memory and I/O modules. 
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ISOMETRIC VIEW 
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IN IN 



HOST 


CONTROLLER 


ADAM 




SYNCHRONIZATION-G-CUEING MICROCONTROLLER 













ADAM - FUNCTIONAL BLOCK DIAGftAM 


(INSTRUCTION WORD FORMAT) 



FIELD 

FUNCTION 

BITS 



1 

BRANCH ADDRESS 

55-40 



2 

CONDITION CODE TEST 

39-37 



3 

BRANCH CONTROL 

36-33 



4 

MEWRY CONTROL 

32-30 



5 

DATA BUS ENABLES 

29-26 



6 

DIV/SQRT/MPY/SIN 

25-21 

1. 

[ 3 INDICATE OPTIONAL ARGUMENT IN 

7 

ALU CARRY SELECT 

20-19 ^ 


INSTRUCTION 

8 

ALU SHIFT SELECT 

18-17 

1 

NOTE THAT ALL CONTROL INSTRUCTIONS 

9 

Rg SELECT 

16-13 I 

[ 

WILL BE ENCODED WITH FIELD 4 SET TO 111 

10 

R^ SELECT 

IB-9 

> ALU 

FIELD 11 SET TO 001. AND FIELD 12 

11 

ALU DESTINATION 

8-6 1 


SET TO 100 ANY OF WHICH MAY BE 

12 

ALU FUNCTION 

S-3 

1 

OVERRIDDEN DURING A MERGE 

13 

ALU SOURCE 

2-0 J 

3. 

REMAINDER OF. FI ELDS DEFAULT TO ^ 


AND MAY BE OVERRIDEN 
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MICROCONTROLLER MEMORY 


dVW 

AHOWaW 

avioi 




i- 


dYW O/I 



+ 





(WVHDOHd) — 

NOISNYdXa — 

. WVH + W0Hd3 

■+ 








VO 

o 


00 

CM 


CM 

CM 

CM 

00 
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MICROPROCESSOR SOFTWARE APPLICATIONS 
FOR FLIGHT TRAINING SIMULATORS 

Wayne P. Leavy 

Goodyear Aerospace Corporation 
Akron, Ohio 


Microcomputer distributed processing may be the answer to modifications 
and improvements for overloaded computer systems of training simulators. Top 
down functional design is a very useful tool for software implementation, and 
the same concept can be applied to a multiple processor computer system. The 
grouping of many independent functions into one large, software module leads 
to confusion, overhead, and inefficiency; the same is true when many large 
mainframe computers are grouped into one system. 

G-cueing is one of the many functions of a pilot training simulator system 
and a unique candidate for the application of distributed computation techniques. 
The G-cueing system must respond to the aircraft six-degree-of-f reedom (DOF) 
equations of motion to provide static and dynamic stimuli to the student pilot's 
proprioceptive, tactile, and visual (with respect to eyepoint) sensors . The cues 
provided by the system must include onset cues as well as sustained acceleration 
cues. 

A G-cueing system has been developed as a strap-on attachment to the F-15 
operational flight training . Simula tor , utilizing a microprocessor computation 
system. Hydraulic actuators produce the onset cues while pressure control of 
AIRMAT pneumatic cushion cells produces seat hardness, softness, and contouring 
to provide for sustained cues. An active lap belt and G-suit is also provided 
to reproduce those sensations experienced in the actual aircraft. 

The interface between the G-cueing system software and the software of other 
simulator systems is very simple: minimal amount of data exchange. However, in 
itself the G-cueing system is a complex system which requires a significant amount 
of computer power. This paper presents the G-cueing system software design ann 
implementation in the dual microprocessor system of the F-15 operational flight 
training simulator G-cueing system. The software is structured in the two micro- 
computers such that one serves as a controller performing all logical functions 
and interface with the host computer system while the other serves as an arith- 
metic unit pierforming all mathematical functions . 


103 



WHY DISTRIBUTED COMPUTATION 7 


(A) 

PILOT 

INPUTS 


• OFFLOAD THE HOST COMPUTER SYSTEM 

• REAL-TIME CONSIDERATIONS 

• COST ADVANTAGES 

• MODULAR HARDWARE (PLUG-IN UNIT) 

• INDEPENDENT DEVELOPMENT (SCHEDULE ADVANTAGES) 


SYSTEM TIME LAG DIAGRAM 



(D) 

155 


(E) 

144.7 
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G-CUING A SELF CONTAINED SYSTEM 


HOST PROVIDES: 

• FRAME SYNCHRONIZATION 

• AERODYNAMIC STIMULI 

• TRAINER MODE 


G-CUING A SELF CONTAINED SYSTEM (CONTD) 

G-CUING SYSTEM PROVIDES: 

• ONSET CUES 

• SUSTAINED CUES 

• BUFFET/VIBRATION CUES 

• G-SUITCUES 

• SAFETY MONITORING 

• CUE SYNCHRONIZATION 


• SELF TEST 



COMPUTATIONAL SYSTEM 



COCKPIT 

INSTRUCTOR 

CONSOLE 
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(D) VIBRATION AMPLITUDE ^ 

(E) SEAT RUN SWITCH ^ SAFETY 

(F) G-SUIT PRESSURE/G ^ 

(G) G-SUIT ON/OFF SWITCH 

























G-CUING SYSTEM DIAGRAM 
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FUNCTIONAL DESCRIPTION OF SOFTWARE 

STARTUP/ FADE IN/ 

SHUTDOWN FADE OUT 



G-CUING SYSTEM 
SOFTWARE APPORTIONMENT 


T 1 9900 PROCESSOR 


8 K ROM MEMORY 

1) 

SELF TEST 

1) 

EXECUTIVE 

2) 

FADE IN/OUT 

3) 

DATA TRANSFER 

4) 

SEAT SAFETY 

5) 

SEAT I/O 

6) 

SEAT OPERATE 

7) 

START UP/SHUT DOWN 


4 K RAM MEMORY 


SCRATCH PAD 


SCRATCH PAD MEMORY 


4 K RAM MEMORY 


1) TEMPORARY 
VARIABLES 

2) DMCP MODULE 
ADDRESSES 

3) VARIABLE GAIN 
ADDRESSES 


D C M P PROCESSOR 


2 K ROM MEMORY 

1) 60 HZ EXTRAPOLATOR 

2) SEAT DYNAMICS 

3) LAP BELT 

4) ACCELERATION 
CURVE SHAPING 

5) G-SEAT 

6) COORDINATE 
TRANSFORMATION 

7) PILOT WEIGHT 
BIAS 

8) SEAT VIBRATION 


3 K MEMORY USED 


1 K MEMORY USED 


0.9 K MEMORY USED 






FUNCTIONAL DESCRIPTION OF 
G-SEAT TO OPERATE 


lOS STATION 



FUNCTIONAL DESCRIPTION OF 
G-SEAT STARTUP/SHUTDOWN 


lOS STATION 



MO emergency off 


LAP BELT TENSION 
FINGER TAPE 
POWER RAIL 







SEAT EQUATIONS OF MOTION 

• PILOT COORDINATES 

Xp = Nj( + PQYcG ~ *“ Y^^CG * ^^CG tYcG 

Yp = Ny + QPXcg + QtZgg - p^Ycg - T^Ycg + tXcg - PZCG 


Zp - N^ + tPXqg ■*■ tQYqq - P^Zqq Q^Zqq - PYqg “ QXqq 


• SEAT ANGLE EFFECTS 
Xgp = Xp COS o — Zp SIN a 

• SEAT ELEMENT COORDINATES 

ELEc A = S {- W,Xsp - W2ZSP - W3YSP 


- PWB 


AUTOMATED ATP OPERATION 




INTEGRATED ATP MODE - BCDE 
HARDWARE ATP MODE -- GDE 
ATP SIGNAL RETURN PATH - UK 
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AN EXPERIMENTAL DISTRIBUTED MICROPROCESSOR IMPLEMENTATION 
WITH A SHARED MEMORY COMMUNICATIONS AND CONTROL MEDIUM 

Richard S. Mejzak 
Naval Air Development Center 
Warminster, Pennsylvania 


An experimental distributed microprocessor subsystem is currently under 
development at the Naval Air Development Center as a vehicle to investigate 
distributed processing concepts with respect to replacing larger computers 
with networks of microprocessors at the subsystem or node level. Major bene- 
fits being exploited include increased performance, flexibility, system avail- 
ability, and survivability by use of multiple processing elements with reduced 
cost, size, weight and power consumption. 

This paper concentrates on defining the distributed processing concept in 
terms of control primitives, variables, and structures and their use in per- 
forming a decomposed DFT (Discrete Fourier Transform) application function. The 
DFT was chosen as an experimental application to investigate distributed pro- 
cessing concepts because of its highly regular and decomposable structure for 
concurrent execution. The design assumes interprocessor communications to be 
anonymous. In this scheme, all processors can access an entire common data- 
base by employing control primitives. Access to selected areas within the com- 
mon database is random, enforced by a hardware lock, and determined by task 
and subtask pointers. This enables the number of processors to be varied in the 
configuration without any modifications to the control structure. Decompositional 
elements of the DFT application function in terms of tasks and subtasks are also 
described. 

The experimental hardware configuration consists of IMSAI 8080 chassis which 
are independent, 8-bit microcomputer units. These chassis are linked together 
to form a multiple processing system by means of a shared memory facility. This 
facility consists of hardware which provides a bus structure to enable up to six 
microcomputers to be interconnected. It provides polling and arbitration logic 
so that only one processor has access to shared memory at any one time. For 
discussion purposes, five of the processors are designated as slaves and one as 
a master where each slave contains an identical copy of a control executive and 
application program tasks. In actual operation, the slave processors cooperate 
to compute the DFT where the master provides external input, output, and control 
functions. With this implementation, commands to perform a DFT iteration are 
provided through the master. 

It is expected that this concept will be tested and demonstrated on a lab- 
oratory model by the end of 1980. Evaluations will concentrate on areas such 
as performance comparisons based on varying the number of processors and bus 
contention factors as a function of local processing and common data base ac- 
cess times. Future work will focus on fault tolerant techniques that can be 
directly implemented and evaluated on the baseline laboratory model. 
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MOTIVATION 

• AVIONIC PROCESSING SYSTEMS ARE BECOMING MORE DISTRIBUTED IN 
ORDER TO EXPLOIT THE FOLLOWING MAJOR BENEFITS: 

- INCREASED SYSTEM WIDE REAL TIME PERFORMANCE 

- EASE OF ADAPTABILITY TO INTEGRATION AND CHANGE 

- HIGH SYSTEM AVAILABILITY 

- DECREASED SYSTEM VULNERABILITY 

• BECAUSE OF REDUCED SIZE, WEIGHT, POWER CONSUMPTION AND COST 
ADVANTAGES, MICROPROCESSOR TECHNOLOGY WILL IMPAa AVIONIC 
PROCESSING SYSTEMS IN THE FOLLOWING AREAS: 

- INTERFACE AND HARDWIRED LOGIC REPLACEMENT APPLICATIONS 

^ - REPLACING LARGER COMPUTERS WITH NETWORKS OF SMALLER 
COMPUTERS 


MICROPROCESSOR TECHNOLOGY AND 
DISTRIBUTED PROCESSING 


REASONABLE COST- PERMITS EXPERIMENTING WITH CONCEPTS WHICH 
WOULD OTHERWISE BE PAPER STUDIES 

REDUCED SIZE, POWER, AND WEIGHT PERMITS APPLICATIONS THAT WOULD 
OTHERWISE NOT BE FEASIBLE 

Life cycle costs often much lower than former solutions to same 
problem 



GLOBAL/ LOCAL DISTRIBUTION 



APPROACH 

• EXPERIMENTAL INVESTIGATION 

• LABORATORY MODEL 

• OFF-THE-SHELF HARDWARE (MICROPROCESSORS ARE INEXPENSIVE) 

- MULTIPLE PROCESSORS 

- SHARED MEMORY FACILITY INTERCONNECT 

• EXPERIMENTAL CONTROL STRUCTURE 

- LOCAL KNOWLEDGE OF EXISTANCE OF OTHER PROCESSORS NOT 
REQUIRED 

- GLOBAL CONTROL AND TASK SCHEDULING VIA HIGHLY RELIABLE 
SHARED MEMORY 

• EXPERIMENTAL WELL-KNOWN APPLICATION-DFT 

• DEMONSTRATE CONCEPT FEASIBILITY 

• PERFORM TRADE-OFF ANALYSES 

• IDENTIFY AND IMPLEMENT FAULT-TOLERANT CONCEPTS 




EXPERIMENTAL HARDWARE CONFIGURATION 


SUVf PMCESSOBS MASTO PRKBSOS 



SHARED MEMORY FACILITY CONSTRAINTS 

• SIX PROCESSORS MAXIMUM 

• ROUND-ROBIN POLUNG SCHEME 

• ONE BYTE ACCESSED PER POLL 

• FIXED LOCK-OUT TIMS IN FUG BLOCK 


ASSUMPTIONS 


• MASTER PROCESSOR PERFORMS INTERFACE AND DISPLAY FUNQIONS 

• SLAVE PROCESSORS PERFORM APPLICATION FUNaiON CONCURRENTLY 
AS DIREaED BY MASTER PROCESSOR 

• LOCAL MEMORY 

- EACH SLAVE PROCESSOR CONTAINS IDENTICAL COPY OF PROGRAMS 

- CONTROL EXECUTIVE 

- APPLICATION TASKS 

• SHARED MEMORY 

- COMMON TO ALL PROCESSORS 

- CONTROL VARIABLES 

- APPLICATION DATA 

- ACCESSED BY CONTROL PRIMITIVES 

- ACCESS RIGHTS ENFORCED BY SEMAPHORES 

• VARYING NUMBER OF PROCESSORS DOES NOT AFFEH CONTROL STRUaURE 




TASK STRUCTURE 



SYSTEM CONTROL: SEMAPHORES 

• ENFORCES ACCESS RIGHTS TO SHARED MEMORY 

• USED TO INDICATE CONDITIONS 

- SHARED MEMORY BLOCKED 

- SHARED MEMORY AVAILABLE 

- ITERATION IN PROGRESS 

- ITERATION COMPLETED 








CONTROL PRIMITIVES 




SEIZE RELEASE 

CONTROL VARIABLES 


BI/TLPt 

FORMAT: 


MSB 


|7T6l^4|3[2| 1| 0] ^ 3tT POSITION (ONE BYTE) 


Bl TLP 

Bl IS a 2 BIT SEMAPHORE AND INDICATES THE FOLLOWING CONDITIONS: 


SEMAPHORE 
B I 


CONDITION 


0 0 

0 I 

t 0 

1 I 


SHARED MEMORY BLOCKED AND ITERATION COMPLETED 
SHARED MEMORY BLOCKED AND ITERATION IN PROGRESS 
SHARED MEMORY AVAILABLE AND ITERATION COMPLETED 
SHARED MEMORY AVAILABLE AND ITERATION IN PROGRESS 


- TLP IS A 6-BIT TASK LIST POINTER THAT CAN POINT TO ANY ONE OF 64 TASKS 


• TS* 

- FORMAT: | t 1 6 | S | 4 |^2 M o] -m BIT POSITION (ONE BYTE) 

-TS* IS AN 8-eiT WORD USED TO ASSOCIATE CORRESPONDING DATA WITH A TASK AND 
CAN TAKE ON 256 VALUES 

• CTCt 

M§g L§g 

-FORMAT: [t | 6 [s[4 [ 3|2| 1 |o) ^ BIT POSITION (ONE BYTE) 


CTC IS AN 8-BIT CUMULATIVE TASK COUNTER. ONE CTC IS REQUIRED FOR EACH TYPE OF TASK BEING PERFORMED, 
i. e.. THE NUMBER OF CTC » ARE EQUAL TO THE NUMBER OF TASKS POINTED TO BY TLP. 





MASTER PROCESSOR CONTROL PRIMITIVES 


SEIZEm PRIMITIVE 

THIS PRIMITIVE IS EXECUTED BT THE MASTER PROCESSOR WHEN ACCESSING SHARED MEMORT 



SEIZEm 

HARDWARE POILING 


LOCKOUT PERIOD 
(NO OTHER PROCESSORS 
CAN ACCESS SHARED 
MEMORY DURING THIS 
TIME) 


OTHER PROCESSORS CAN AC- 
CESS SHARED MEMORY BUT NO 
VARIABLES CAN BE DISTURBED 
UNTIL MASTER PROCESSOR 
RELEASES SNARED MEMORY TO 
THE SLAVE PROCESSORS BY 
MEANS OF THE RELEASEm 
PRIMITIVE 


• RELEASEm PRIMITIVE 

THIS PRIMITIVE IS EXECUTED BY MASTER 
PROCESSOR WHEN RELEASING SHARED MEMORY TO 
THE SLAVE PROCESSORS FOR PERFORMING AN ITERATION 



SLAVE PROCESSORS CAN 
NOW SEIZE SHARED MEMORY 


SLAVE PROCESSOR CENTROL PRIMITIVES 

• SEIZES PRIMITIVE 

THIS PRIMITIVE IS EXECUTED BY THE SLAVE PROCESSORS WHEN ACCESSING SHARED MEMORY 



SEIZES 

HARDWARE POLLING 


Y LOCKOUT PERIOD =At 
(NO OTHER PROCESSORS 
CAN ACCESS SHARED 
MEMORY DURING THIs 
TIME) 


OTHER PROCESSORS CAN AC- 
CESS SHARED MEMORY BUT NO 
VARIABLES CAN BE DISTURBED 
UNTIL ACCESSING PROCESSOR 
RELEASES SHARED MEMORY BY 
MEANS OF THE RELEASES 
PRIMITIVE 


RELEASES PRIMITIVE 
THIS PRIMITIVE IS EXECUTED BY SLAVE 
PROCESSORS WHEN RELEASING SHARED MEMORY 





















DFT APPLICATION 


A DFT CAN BE DEFINED IN THE FOLLOWING MATRIX FORM; 

G = WF 
IF WE LET: 

• n = 0,1.2 N-1 = MATRIX ROW NUMBER AND FREQUENCY SHP 

• k = 0,1,2 k-1 = MATRIX COLUMN NUMBER AND TIME STEP 

• N = k BUT MAINTAINING n AND k NOTATIONS TO DISTINGUISH ROWS FROM COLUMNS 
THEN: 

• W IS AN N X k MATRIX CONSISTING OF THE HRMS 

e(-3^/N)(Rk MOD N) 

= COS [(^)Rk MOD N)] - j SIN [(3^(nk MOD N)] 

• F IS A kxl MATRIX REPRESENTING THE FUNaiON F(tk)T/7int OVER THE TIME SPAN T 



\gN-i/ XwN I.O ,^N I,K.| W»**IK V \FtX-1T/2 7T K 

SINCE: 

Gn,k (REAL) = COS ((^)(nk MOD N)] F(tk) T/2 Ok 
Gfl.k (IMAGINARY) {siN [(^(nk MOD N)j}F(ffc) T/2 rr k 
UJn = nAwWHEREAu^= 



THE AMPLITUDE/FREQUENCY VALUES CAN BE OBTAINED AS FOLLOWS: 
=AW|G«| 
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AMPUroOC 


INPUT/OUTPUT 



DFT DECOMPOSITION FOR TASK 1 


SUBTASK 1 OF N 



input process output 

(SHARED MEMORY) (LOCAL MEMORY p) (SHARED MEMORY) 
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DFT DECOMPOSITION FOR TASK 2 





SUBTASK10FK 


SUBTASK 2 OF K 


SUBTASK K OF K 


DFT DECOMPOSITION FOR TASK 3 


SUBTASK 1 OF N 


X Co(R) 
X 01(R) 


SGN-HR) 
X Go(l) 

% G1(l) 

S GN-1(I) 



-Ij— 

INPUT-OUTPUT OF TASK 2 
(SHARED MEMORY) 


V / 

PROCESS 

(LOCAL MEMORY p) 


OUTPUT 

(SHARED MEMORY) 


INPUT 


PROCESS 


OUTPUT 




STATUS 

• IMPLEMENTATION 

• GCSS SIMULATION 

• LABORATORY EVALUATION 

• FAULT TOLERANT STUDIES 

- PROCESSOR 

- SHARED MEMORY 

- BUS 


RELIABILITY MODEL 


1 OF N 



• TAKE ADVANTAGE OF MULTIPLE 
PROCESSORS 

• OPTIMIZE EXISTING CONTROL 
STRUaURE FOR FAULT- 
TOLERANCE PURPOSES 


• CURRENTLY SINGLE POINT FAILURES 

• STUDIES TO IDENTIFY FAULT TOLERANT 
SCHEMES 

• POSSIBLE IMPLEMENTATION OF HIGHLY 
RELIABLE SHARED MEMORY WOULD 

BE DUPLEXED CONFIGURATION 
EACH WITH SINGLE ERROR CORREaiON 
AND DOUBLE ERROR DETEaiON 
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DISTRIBUTED MICROPROCESSORS IN A TACTICAL UNIVERSAL MODEM 

D. M. Gray, J. B. Malnar, and H. Vickers , 

Harris Corporation 
Melbourne, Florida 

The Wideband Signal Conversion Unit (WBSCU) for the Tactical Information 
Exchange System (TIES) is a four-channel software reprogrammable modem. System 
goals are high resource availability, growth potential, reliability, and graceful 
degradation. The WBSCU processes JTIDS, GPS, IFF/OABS, and TACAN waveforms 
simultaneously under direction of a host computer. For both complex spread 
spectrum and pulse-based waveforms, the WBSCU provides matched filtering, signal 
processing, error detection/correction and encoding/decoding, and data 
communication via IEEE 488 and MIL-1553 buses. 

Multiple embedded 8086 and 2901 microprocessors, supported by dedicated 
hardware modules, perform the required real-time operations for both transmit and 
receive functions. Commands from a host computer determine the configuration of 
the WBSCU via the IEEE 488 bus. Each of the four WBSCU channels is assigned to 
process a specified IF waveform; each channel configures its own resources and, in 
some cases, borrows resources from other channels. The processed waveform data is 
communicated from individual channels to redundant global memories. Data flow 
between the user community and global memories occurs via redundant 1553 buses 
through intelligent Bus Interface Units. 

Each WBSCU channel contains one 2901 bit-slice machine and one 8086 
microprocessor. The 2901 provides high-speed processing capability for the most 
time-critical operations. Features include a 16-bit word size, 64-bit microcoded 
instruction, and 10 MHz instruction throughput. The 8086 is used for lower speed 
processing tasks where its high level language capability can be better exploited. 
Each 8086 has a global bus for wideband interprocessor communication, and a local 
bus for 8086/2901, master/slave communication. Software architecture consists of a 
control and communications structure governing mode-dependent signal processing 
tasks. 

In GPS data acquisition, the 2901 processes array correlator outputs 
and generates code and carrier error signals. The 8086 implements the loop filters 
required to achieve code lock and carrier synchronization, performs error detection 
and extracts message bits at a 50 b/s data rate. This data is output via the 
global memory. During JTIDS signal processing, the 2901 controls hardware modules 
to generate the acquisition strobe and time refine signals, readying the system to 
receive the data message. The 8086 performs message level data processing for 
both transmit and receive functions, data routing, and interchannel communications. 
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TIES/WBSCU 
Block Diagram 
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Single Channel WBSCU 
Configuration 
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CARRIER TRACK 




Local 8086 Architecture 
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LOCAL 

EVENTS 




2901 Bit-Slice Microprocessor 


8086 WRITE/READ 


MICRO CONTROLLER 


WRITABLE CONTROL 
STORE 

CONTROL LOGIC 
PIPELINE REGISTER 


8086 ADDRESS BUS 


PROCESSING ELEMENT 


• INPUT MUX 

• 4 290rsF0RALU 

• 2902 LOOK AHEAD 


8086 DATA INTERFACE 

a i 

k 

1 

f 2901 LOCAL DATA BUS 


TO/FROM MISC FUNCTIONS 


MULTI USE BUS 


ADDRESS REG NO. 1 


LOCAL DATA 
MEMORY 
(IK WORDSI 


ADDRESS REG NO. 2 


ADDRESS REG NO 3 


LOOP COUNTER 


8086 ADDRESS 
INTERFACE 


CONTROL LINES 
TO HARDWARE MODULES 


MICRO CYCLE RATE: 8 MHi 
CONTROL RAM IS INTEL 2148 
CONTROL WORD IS 64 BITS WIDE 
SOME OF THE CONTROL WORD FIELDS ARE: 

- REGISTER A SELECT (4 BITS) 

- REGISTER 8 SELECT 

- 2901 INSTRUCTION SELECT (9) 

- CARRY IN (1) 

- ADDRESS REGISTER TS EN (3) 

- SHIFT MUX CONTROL (2) 

(ALSO USED FOR INPUT MUX CONTROL) 

- PRE MUX CONTROL (2) 

- FLAG MUX CONTROL (2) 

- DISCRETE-OEVICE-OEMUX CONTROL (4) 

-- MISCELLANEOUS DISCRETES (15) 

- PART OF THE NEXT MICRO MEMORY ADDRESS (9| 

A 12 BIT MULTI USE BUS IS MADE UP FROM THE REGISTER FIELDS AND 
PART OF THE INSTRUCTION FIELDS: THE 2901 IS NO OP ed WHEN THE 
MULTI USE FIELD IS USED 


[P 
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MICROCOMPUTER SOFTWARE DEVELOPMENT FACILITIES 

J. S. Gorman and C. Mathiasen 
Ford Aerospace 
Houston, Texas 


Historically, microcomputer software/firmware has been developed on a system designed to 
perform softwcire development eind emulation functions for a specific processor. This 
method proved successful during the early years of microcomputer software development. 
However, both the number of microcomputers used in system design, and the complexity of 
the microcomputer software, have increased. These chamges dictate that more efficient and 
cost effective methods be found for developing microcomputer software. 

One approach is to utilize a host computer with high-speed peripheral support. Application 
programs such ais cross assemblers, loaders, and simulators are implemented in the host 
computer for each of the microcomputers for which software development is a requirement. 
The host computer is configured to operate in a time-share mode for multi-users. The 
provided remote terminals, printers, and down loading capabilities are based on user 
requirements. With this configuration a user, either local or remote, can use the host 
computer for microcomputer software development. Once the software is developed 
(through the code and modular debug stage) it can be downloaded to the development system 
or emulator in a test area where hardware/software integration functions can proceed. The 
microcomputer software program sources reside in the host computer and can be edited, 
assembled, loaded, and then downloaded as required until the software development project 
has been completed. 

The use of a host computer for microcomputer software development allows greater 
expansion and versatility and has resulted in increased performance and improved program- 
mer productivity. 
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Microcomputer Software Development 
History 

• Traditionally accomplished on dedicated development systems 

• Development systems supported one specific processor or processor sets 

• Minimal operating systems dr monitor programs supplied for run 
time and development support 

• Standard utilities provided: assemblers and editors 

• Development method initially adequate 


The Need for Change 

• Increasing software complexity surfaced many problems 

• Single user environment time consuming, Inefficient 

• Difficult to support more than one type of target processor 

• Development systems provided minimum peripheral support 

• Development capability relatively slow 

• Non-availability of development system became serious problem 
§ Need for change eminent 



Host Computer System Philosophy 

• Use of host computer system solves many problems i 
f Host computer can service multi-user environment 

9 

• Via cross-product software, one host computer can support any 
number of target processors 

• Host computer peripheral support can be wide and varied 

f Host computer provides substantial, resident development tools 
f Host computer can support remote development facilities 
f Once software developed, can be downloaded to target processor 

• Debug and integration can continue via in-circuit emulators 


Implementation: Hardware 
Implications 

• Terminal, printer, and download line selection can be determined 
from user requirements 

f Communication equipment selection can be determined by data rates, 
line protocol, transmission distances, and signal multiplexing 

t Computer interfacing equipment selection can be determined by 
I/O availability and user equipment interface characteristics 

f Remote printers and host computers must support busy/ ready 
indication using modem circuits 

• Using standard host computer interface protocol in user equipment 
can minimize computer Interface driver modifications 
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Implementation: 

Software Implications 

0 First priority: selection of cross-product software 

• ■ 

0 If local talent and experience available, software products can be 
developed instead of purchased 

0 Off-the-shelf assemblers and high level language compilers will support 
most processors 

0 Most vendors supply executable format software only. Some vendors 
provide source code 

0 Software for simulation capability should also be purchased 

0 Via total cross-product software package and host system development 
facilities, software can be checked out through software -to -software 
integration phase 


Possible Obstacle: Transferring 
Software to Target Processor 

0 Use like peripherals on both host system and target processor 

0 Host computer flexible disk system can simplify software transfer 

0 Host computer flexible disk system can also provide source code archival 

0 Flexible disk formats must be hardware and software compatible with 
target processor format 

0 If host computer is remote from target processor, shuttling diskettes 
back and forth can lead to additional software transfer method analysis 
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Developing A Downloader Capability 

• Some vendors supply downloader software 

• Development involves minimal software effort 

• Downloader approach involves use of development system or emulation device 

• Can use dedicated development system or emulator port for host computer 
interface 

• Via download lines, can use I/O device on development system or emulator 
to communicate with host computer 

• Two downloading philosophies 

" Controlled method 
— Pseudo terminal method 

• Same environment will also support upload capability 


Avoiding Pitfalls 

• Consider many issues during planning stages 

• Host computer memory limitations can also limit performance and efficiency 

• Host computer task size limits can increase overlay needs 

• Cross-product software idiosyncracies can limit software transportability 

• Investigate symbol table and macro limitations before purchasing cross- 
product software 

• If source code purchased, additional cost factors can surface 

• Development facility personnel must be adequately trained in host computer 
use and cross-product software 
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Typical Microcomputer Software 
Development Facility Configuration 
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MICROPROCESSOR USER SUPPORT AT LANGLEY RESEARCH CENTER 

Jerry H. Tucker 
Langley Research Center 
Hampton, Virginia 


The microprocessor is the most significant advance in electronics since 
the invention of the transistor. We are building systems today with 
microprocessors that a few years ago would have been completely impractical or 
extremely expensive. Microprocessors provide numerous advantages to the 
system designer such as lower cost, reduced development time, increased 
flexibility, and increased reliability. Despite these advantages, the use of 
microprocessors pose significant problems. These include: 

(1) A long learning process for proficient use of microprocessors. 

(2) The requirement for extensive support in both hardware and software. 

(3) The need for coordination and sharing of the creative effort to 
avoid unnecessary duplication. 

The following steps have been implemented at Langley Research Center to 
address these problems. 

(1) The establishment of a microprocessor users committee to provide 
an advisory interface for management and users. 

(2) The training of microprocessor users. 

(3) The publication of a newsletter to dissiminate information among 
microprocessor users • 

(4) The use of both cross^sof tware on the central computer complex and 
microprocessor development systems to support the design of 
microprocessor based systems. 

This presentation provides a general overview of microprocessor user 
support at Langley Research Center, including a detailed review of each of the 
above items. Special emphasis is given to the microprocessor support 
available from the central computer complex. An assessment of the 
effectiveness of the approach being taken at Langley is given. In addition , 
specific hardware and software development efforts that are targeted toward 
enhancing the existing microprocessor support is discussed. 
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MICROPROCESSOR SUPPORT AT LANGLEY RESEARCH CENTER 

• MICROPROCESSOR USER'S COMMITTEE 

• CENTRAL COMPUTER COMPLEX SUPPORT 

• LOCAL MICROPROCESSOR SYSTEM DEVELOPMENT LABS 


MICROPROCESSOR USER'S COMMITTEE 

CONSISTS OF KEY MICROPROCESSOR USERS 
ADVISES IVIANAGEMENT AND USERS 
ASSISTS IN PROVIDING USER TRAINING 

ASSISTS IN DEFINING REQUIRED HARDWARE AND SOFTWARE SUPPORT 

COMMUNICATES TO USER COMMUNITY VIA A "MICRO-NEWSLETTER" 

(sent to 200 people) 



CENTRAL COMPUTER COMPLEX SUPPORT 


• MAINTAINS MICROPROCESSOR SUPPORT SOFTWARE 

- ASSEMBLERS (14) 

- COMPILERS ( 4) 

- SIMULATORS (12) 

- UTILITY PROGRAMS 


• IN-HOUSE DEVELOPMENT 

- ASSEMBLERS, DISASSEMBLERS 

- 8748 PASCAL COMPILER 

- 68000 HALS COMPILER 

- CENTRAL COMPUTER COMPLEX LINKS TO MICROPROCESSOR LABS 
HARDWARE AIDS FOR USERS 


MICROPROCESSOR SUPPORT MAINTAINED ON LRC-; CENTRAL COMPUTER COMPLEX 


MICROPROCESSOR 

DESCRIPTION 

ASSEMBLER 

SIMULATOR 

HOL 

8086 

Intel 16-Bit 




68000 

Motorola 16-Bit 



PASCAL (HALS) 

9900 

Old 16-Bit 




8080/8085 

8-Bit 

I 

i ^ 

PLM 

6800/6802 . . . 

8- Bit 



MPL 

Z-80 1 

8- Bit, Super 8080 



8080 PLM 

6809 

8-Bit, Super 6800 

1 



8748/8741 

8-Bit, Single Chip 



PASCAL 

1802 

8-Bit 




6502 

8-Bit 




4040 

4-Bit 






LOCAL MICROPROCESSOR SYSTEM DEVELOPMENT LABS 


• Typical Lab (ACD's) 

- Intel Development System linked to Central Computer Complex 

- Over a dozen users with standard procedures and documentation 

- Assemblers for B080/8085, 8748/8741, 8086/8088 

- PLM compilers for 8080/8085, 8086/8088 

- FORTRAN for 8080/8085 

- IN-CIRCUIT EMULATORS (ICE) for 8080, 8085, 8748, 8086, 3000 

- E PROM PROGRAMMER 

• Local Microprocessor Development Systems at Langley 


Intel 

(7) 

Motorola 

(5) 

Tektronix 

(2) 

Texas Instruments 

(2) 


CHARACTERISTICS OF MICROPROCESSOR SOFTWARE ON' CENTRAL COMPUTER CO/VIPLEX 


• STRENGTHS 


- UNIVERSAL 

- SIMULTANEOUS USERS 

- FAST 

- FLEXIBLE 

- TAKES ADVANTAGE OF EXISTING RESOURCES 


• WEAKNESSES 


- RELATIVELY DIFFICULT TO LEARN (COMPLEX OPERATING SYSTEM AND EDITOR) 

- LACK STATE OF THE ART SOFTWARE 

- CANNOT SIMULATE ENTIRE SYSTEM 

- FRAGMENTS DEVELOPMENT PROCESS 
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DEBUGGING EMBEDDED COMPUTER PROGRAMS 
Gilbert H. Kemp 

General Dynamics/Western Data Systems Center 
Pamona, California 


The debugging of embedded digital computer programs is a function that can use 
a wide range of support tools from essentially none to sophisticated systems. 
Every embedded computer program must complete its debugging cycle using some 
system that will allow real time debugging. 

A listing of many of the common items addressed during debugging is given. 

Several approaches to debugging are analyzed to evaluate how well they treat 
those items. Cost evaluations are also included in the comparison. 

The approaches compared are: (1) no software support, (2) embedded computer 

augmented with additional software for debugging purposes, (3) microprocessor 
development systems, (4) an environment simulation and interpretive computer 
simulation combination run on a large scale computer, (5) an environment simu- 
lation on a hybrid computer coupled with the embedded computer, (6) an environ- 
ment simulation on a midi-computer coupled with an emulation of the embedded 
computer, and (7) an environment simulation on a midi-computer coupled with a 
slightly modified embedded computer. 

The results of the comparison indicates that the best collection of capabilities 
to cover the common items present, in the debugging task occurs in the approach 
where a midi-computer handles the environment simulation with an emulation of 
some kind representing the embedded computer. This approach can be taken at a 
reasonable cost. 

The case study chosen is an embedded computer in a tactical missile# Several 
choices of computer for the environment simulation are discussed as well as 
different approaches to the embedded computer emulator. 

The selected choice for computer the environment simulation is a special-purpose 
computer designed to rapidly solve differential equations. The Applied Dynamics 
International AD-10 computer is an example of this type. This appears to be 
capable of solving a full 6 Degree of Freedom missile simulation in real time. 

The proposed choice for emulating the embedded computer is to use a modified 
version of the embedded computer itself. It is called an "Extended” computer. 

The "extension” amounts to adding extra bits to the program memory. When an 
instruction is loaded for execution, an interrupt will occur if one of these 
extra bits is up. Software interrupt service routines will determine what debug- 
ging function is to occur, e.g., start a trace. 

The conclusion is that the use of the AD-10 and "Extended” embedded computer will 
show a debugging cost savings approaching 44 percent over the current commonly 
used team of Interpretive Computer Simulation used in conjunction with a hybrid/ 
embedded computer pair. 

Reference 

Glass, Robert L., **Real-Time: The 'Lost World* Of Software Debugging and 

Testing”^ Comm, ACM 23, 5 (May 1980), Pages 264-271. 
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DEBUGGING EMBEDDED COMPUTER PROGRAMS 
FOR ANY TASK: 

0 IMPROVED PRODUCTIVITY IS DESIRABLE 
0 BETTER TOOLS CAN IMPROVE PRODUCTIVITY 
0 THE TOOLS MUST BE COST EFFECTIVE 

APPLYING THESE THOUGHTS TO THE TASK OF DEBUGGING EMBEDDED DIGITAL 
COMPUTER PROGRAMS WILL BE DISCUSSED. 


POMONA DIVISION DESIGNED DIGITAL COMPUTERS 


COMPUTER 

YEAR 

DESIGNED 

NUMBER 

OF 

INSTRUCT. 

NUMBER OF 
GEN. PURPOSE 
REGISTERS 

INTER- 

RUPTS 

SHORTEST 
INSTRUCTION 
TIME (MSEC.) 

RELATIVE 
TIME OF 
EXECUTION 

TECH- 

NOLOGY 

MICRO 

CODED 

A 

1971 

24 

2 

NONE 

0.4 

1.0 

HARD WIRED 

NO 

B 

1975 

74 

4 

ONE 

0.9 

3.1 

BIT SLICE- 
INTEL 3000 

YES 

C . 

1976 

102 

8(16) 

VECTORED 

0.4 

1 .2 

BIT SLICE- 
AMD 2900 

YES 

D 

1978 

158 

9(17) 

VECTORED 

0.3 

0.8 

BIT SLICE- 
AMD 2900 

YES 
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ITEMS IN DEBUGGING 


A. INPUT -- HARDWARE AND CONVERSION 

B. OUTPUT — HARDWARE AND CONVERSION 

C. MATHEMATICAL CALCULATIONS 

D. LOGIC DECISIONS 

E. CHECK ALL PATHS OUT OF DECISIONS 

F. OVERFLOWS 

G. MAXIMUM USE OF PRECISION WITHOUT OVERFLOW 

H. LACK OF SIGNIFICANCE 

I. INITIALIZATION OF VARIABLES 

J. TIMING OF THE PROGRAM 

K. PROCESS SWITCHING 


DEBUG TECHNIQUES 

A. TRACING SELECTED SECTIONS OF THE PROGRAM AT APPROPRIATE 
TIMES 

B. ANALOG RECORDING OF SELECTED VARIABLES OF THE PROGRAM 

C. PRINTING SELECTED PROGRAM VARIABLES AT APPROPRIATE TIMES 

D. STOPPING ON BREAKPOINTS AND EXAMINING CONTENTS OF REGISTERS 
AND MEMORY 



COMPARISON OF DEBUG TECHNIQUES 
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EMULATION APPROACHES 


BITS 
0001 X 

OIOIX 

OlOOX 

lOOOX 

101 OX 
1100X 

lllOX 


ENVIRONMENT 

COMPUTER 

EMULATION 

COMPUTER 

VAX 

QM-1 

VAX 

“EXTENDED" 


TARGET 

AD-10 

"EXTENDED" 


TARGET 

FUNCTIONS 

OF THE ADDED BITS 


FUNCTION 


IGNORE AN OVERFLOW ON THIS INSTRUCTION IF IT OCCURS, 

otherwise print an error message if an overflow occurs. 

CAUSE PROGRAM TO BECOME SYNCHRONIZED WITH ENVIRONMENT 
COMPUTER PROGRAM. 

BREAKPOINT. 

START A TRACE— IF TIME HAS REACHED A SPECIFIED VALUE. ALSO 
SET A FLIP-FLOP TO COMMAND AN INTERRUPT TO PRINTOUT TRACE 
DATA ON EACH SUCCEEDING INSTRUCTION. 

STOP TRACING, I. E. , RESET THE TRACE FLIP-FLOP. 

START TIMING FROM POINT A TO POINT B IF RUN TIME HAS REACHED 
A SPECIFIED VALUE, I.E., READ THE CLOCK OF TARGET OR ENVIRON- 
MENT COMPUTER. 

STOP TIMING— READ THE CLOCK OF TARGET OR ENVIRONMENT COMPUTER 
AND PRINT THE DELTA TIME SINCE TIMING STARTED. 




ENVIRONMENT COMPUTER/"EXTENDED" TARGET COMPUTER BLOCK DIAGRAM 




OVERALL COMPARISON OF DEBUG TECHNIQUES 

APPROACH 

ADVANTAGES 

DISADVANTAGES 

ACTUAL TARGET COMPUTER. 

LEAST EXPENSIVE RE HARDWARE. 

NOT ENOUGH TOOLS. 
TOO PRIMITIVE. 

MDS 

INEXPENSIVE RE HARDWARE. 

NOT ENOUGH TOOLS. 
TOO PRIMITIVE. 

INTERPRETIVE COMPUTER 
SIMULATION (I.C.S.) ON A 
LARGE COMPUTER PLUS HYBRID 
PAIR--USEO SEPARATELY. 

GOOD SET OF TOOLS. 
HYBRID IS REAL-TIM^ 
HYBRID USES REAL TARGET 
COMPUTER. 

CURRENT METHOD IN USE. 

VERY EXPENSIVE RE HARDWARE AND 
OPERATING COSTS. 

I.C.S. TURN AROUND IS SLOW. 

VAX FOR MISSILE SIMULATION 
PLUS QM-1 FOR TARGET. ‘ 
EMULATION. 

GOOD SET OF TOOLS. 

EMULATE NON-EXISTENT TARGET 
COMPUTER. 

LESS EXPENSIVE THAN I.C.S. 
PLUS HYBRID. 

VERY SLOW. 

MULTI-CPU TARGET EVEN SLOWER. 

VAX FOR MISSILE SIMULATION 
PLUS “EXTENDED” TARGET 
COMPUTER. 

GOOD SET OF TOOLS. 

USES REAL TARGET COMPUTER. 
ALLOWS MULTI-CPU TARGET. 
LESS EXPENSIVE THAN VAX 
PLUS QM-l. 

NOT REAL-TIME. 

REQUIRES VERIFICATION OF 
"EXTENDED” TARGET COMPUTER 
CONCEPT. 

ADIO FOR MISSILE SIMULATION 
PLUS "EXTENDED” TARGET 
COMPUTER. 

. GOOD SET OF TOOLS. 

USES REAL TARGET COMPUTER. 
ALLOWS MULTI -CPU TARGET. 
REAL-TIME! 

LESS EXPENSIVE THAN VAX 
PLUS "EXTENDED" TARGET. 
BEST OVERALL APPROACH. 

REQUIRES VERIFICATION OF AOlO 
SPEED. 

REQUIRES VERIFICATION OF 
"EXTENDED" TARGET COMPUTER 
CONCEPT. 
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REAL-TIME OPERATING SYSTEM FOR SELECTED INTEL PROCESSORS 

W. R. Pool 
Ford Aerospace 
Houston, Texas 


This paper addresses development of a real-time operating system for selected Intel 
processors, in terms of four project phases. 

The first phase develops the system development rationale. Included are reasons for not 
using vendor supplied operating systems. The second phe«e deals with the system design and 
performance goals. While many of these goals are dictated by problems with vendor 
supplied systems, other goals surfaced as a result of a design for a custom system able to 
span multiple projects. The third phase deals with system implementation. Discussed are 
system development and management problems and areas that required redesign or major 
code changes. The final phase deals with project results. First, the relative successes of 
the initial projects are develop>ed. Then, a generic description of the actual project is 
provided. Finally, the ongoing support requirements and future plans are discussed. 


preceding Pa9® 
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Make/Buy: Requirements Make the Decision 


• First, determine what system must do 

" Reai-time - quick response 
" Muiti-tasking - priority scheduiing 
" High performance, especiaiiy for i/0 
" Disk fiie system compatibie with ISiS-ll 
" Biock mode CRT support 

t Seiection: what wiii do the job ? 

— Does system exist that meets requirements ? 

" Can a system be modified at less expense/time ? 

• Developing your own 

" Does talent exist ? 

" Is there time/money ? 

— Are development facilities available? 


System Design: A Reai Experience 


Design Goals 

• Modification ease: add foreign devices 

• Modular: use only necessary parts 

• Standard device interfaces to applications 
: jC Sup^ any board/device configuration 
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System Design: A Real Experience (Cont’d) 


Control Element Components 


Control Program 

• Task Management 

• Event Signaling 

• I/O Control 

• Interrupt and Device Handling 


Control Block 
Task Control Block (TCB) 
Event Control Block (ECB) 
File Control Block (FCB) 
Device Control Block (DCB) 


System Design: A Reai Experience (Cont’d) 

Utility Functions 

t Display support 

• Disk file management 

• Loader 

• Operator interface 

• Advisory facilities 

• Debug monitor 

Additional Services 

• Timer services 

• Dynamic memory allocation 
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Implementation: No Easy Victories 


The Team 

• Designer: control block contents, program functions 
0 Programmer: program design, development 

The Plan 

0 Develop task management, interrupt service, and I/O initiation first 
0 Validate control block structure 
0 Correct any control block and design errors 
0 Rewrite as necessary 
0 Develop device support and utilities 


Implementation: No Easy Victories (Cont’d) 

The Problems 

0 Development systems slow and unreliable 

0 Processor poorly suited for multi-tasking and re-entrant code 

0 Early delivery resulted in system not fully checked out 

0 Tight bindings must be replaced with loose binding to separate OS from 
applications 

0 User documentation slow/non-existent 

0 Disk support control block formats must be changed to support different 
densities 

0 Dynamic memory support should have been included in original design 

0 Needed to fund support group as user group increased 

0 Configuration control problems due to different releases on projects and 
inadequate library facilities 

0 Should have had cross software and timesharing network at beginning 



Results 


Met All Requirements and Design Goals 

f Currently used in three systems; being implemented in four others 
t Being used in different hardware configurations 
t Interrupt processing capabilities faster than other available systems 

• Achieved true multi-tasking capabilities 

Cost Effective 

• Effort and budget savings via use on multiple projects 
t No license fees 


Results (Cont’d) 

System Characteristics 

• 6 months to produce first version; 1 year to produce debugged version 
in macro form 

• 4K PROM for basic system with task management, I/O support, and loader 

• 8K PROM adds display support, debug monitor, advisory, and full disk 
support 

• 4-12K of RAM necessary for buffers and control blocks 

• Normally will support CRT, line printer, and two flexible disk drives 

• Systems usually embedded in larger equipment systems 



Future Plans 


• Recode for different processor 

• Change user interface to loose binding type 

• Augment dynamic memory support 

• Convert to higher level language 

• Provide support for users/projects 

• Redesign disk support/control block 

• Provide software library on host development system 
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A FOURIER TRANSFORM WITH SPEED IMPROVEMENTS FOR 
MICROPROCESSOR APPLICATIONS 

Donald C. Lokerson 
Goddard Space Flight Center 
Greenbelt, Maryland 

and 

Dr. Robert Rochelle 
University of Tennessee 
Knoxville, Tennessee 


A fast Fourier transform algorithm for the RCA 1802 microprocessor has been developed 
for spacecraft instrument applications. The computations have been tailored for the restrictions 
an eight bit machine imposes. 


The algorithm incorporates some aspects of Walsh function sequency to improve operational 
speed. This method uses a register to add a value proportional to the period of the band being 
processed before each computation is to be considered. If the result overflows into the “DF” 
register, the data sample is used in computation; otherwise computation is skipped. This opera- 
tion is repeated for each of the 64 data samples. This technique is used for both sine and cosine 
portions of the computation. 


The processing uses eight bit data but, because of the many computations that can increase 
the size of the coefficient, floating point form is used. 

A method to reduce the alias problem in the lower bands will also be described. 
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SAMPLE #1 8 16 24 32 





159 



22 


FAME— A MICROPROCESSOR BASED FRONT-END ANALYSIS AND 
MODELING ENVIRONMENT 

Jacob D. Rosenbaum and Edward B. Kutin 
Higher Order Software 
Jericho, New York 


FAME, (Front-End Analysis and Modeling Environment) is a micro- 
processor based interactive computer aided design aid, for designers 
and developers of computer-based systems. FAME is especially useful 
in microprocessor applications where systems complexity has increased 
the need for more rigorous approaches to the development process. 

A variety of techniques and methods are being proposed by govern- 
ment and industry to meet the extensive need for better approaches to 
development, documentation and verification of systems. Some of the 
more widely used include; formal specification of system requirements 
and designs, static analysis of related models, and simulation to in- 
sure that the system to be developed meets the intended objective. To 
date, support of these activities involve large, costly computerized 
systems or extensive manual procedures. 

Higher Order Software (HOS) is a methodology for the specification 
and verification of large scale, complex, real-time systems. An emphasis 
in its development has been the aerospace environment. Typical systems 
applications include guidance and control, navigation, communications, 
radar imaging, satellite tracking and many others. The methodology 
integrates Functional Decomposition, Abstract Data Types, and Control 
Structures in accordance with a set of axioms that describe decomposition 
rules, nodal relationships and responsibilities. The systems models 
produced can be verified statically using small amounts of computer 
resources and time. 

The HOS methodology has now been implemented as FAME (Front-End 
Analysis and Modeling Environment), a microprocessor based system for 
interactively developing, analyzing and displaying system models in a 
low cost user-friendly environment. The nature of the model is such 
that when completed it can be the basis for projection to a variety of 
forms such as Structured Design Diagrams, Petri-Nets, Data Flow Diagrams, 
PSL/PSA Source Code etc. The user's interface with the analyzer is 
easily recognized by any current user of a structured modeling approach; 
therefore extensive training is unnecessary. Furthermore, when all the 
system capabilities are used one can check on proper usage of Data Types, 
Functions and Control Structures and thereby add a new dimension to the 
design process that will lead to better, and more easily verified soft- 
ware designs. 

FAME is now available on a range of computer systems as well as 
on any Microprocessor with 64K of memory and dual floppy disks that can 
use the CP/M operating system. It is especially useful on Microprocessor 
Development Systems where one would now be able to combine the require- 
ments, documentation analysis, verification and code development, activities 
on a single device. 

Preceding Page Blank 
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FAME CAPABILITIES 



BENEFITS OF HOS 


0 MODELS ARE VERIFIABLE STATICALLY 

0 MODELS INTEGRATE 

- FUNCTIONS. 

- DATA TYPES 

- LIBRARIES OF OPERATIONS & STRUCTURES 

- RULES FOR MODEL CREATION 

0 SUPPORTS ALL PHASES OF DEVELOPMENT 
0 MODELS CAN SUPPORT DIRECT SIMULATION 
0 MODELS CAN PROVIDE EXTRACTS TO SATISFY OTHER METHODS 

0 AN HOS ANALYSIS REQUIRES KNOWLEDGE OF ONLY A PARENT & ITS OFFSPRING 





COST BENEFITS OF FAME ON MICRO 


0 OFFLOADS MAINFRAME T/S SYSTEMS 

0 PROVIDES GOOD RESPONSE a<$^I/HOUR 

0 MINIMUM LINE CHARGES 

0 HOS MODELING & ANALYSIS COSTS ESTIMATES (ON 8080 MICROCOMPUTER) 


MODELING PHASE 

DECOMPOSITION 

ANALYSIS 

DISPLAY 


Cl ocK minutes/nqde 

15 MIN 
1.5 MIN 
1,0 MIN 


NODES INVOLVED 

PARENTS 
PARENTS 
PARENTS . 


CURRENT STATUS 


0 PROTOTYPE (C BASIC) ON 8080 MICRO-COMPUTERS (cPM) 

0 PROTOTYPE (C BASIC) ON INTEL MDS 

0 PASCAL VERSION ON MICRO ( I N DEVELOPMENT) 

0 PASCAL VERSION ON VAX 11/780 

0 CURRENTLY REHOSTING TO: 

- HARRIS 

- CONTROL DATA (CYBERNET) 

- MULTICS 
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MODEL OF SATELLITE NAVIGATION SYSTEM 



. PARF.NT/OFFSPRIMG DIAGRAM 

HOG/ FROM I -END ANALYSIS AND MODELING ENVIRONMENT 
SATELLITE NAVIGATION MODEL NAME: SATNAV 

SYSTEM author: EK 

pate/time: 7/m 


OUrPUTS INPUTS 


. : ADD ; 

YSATST :PERF0RM : XSATST 

‘.automatic ; SSETIM 

: processing: lsetpl 

:functions ; cstsim 


O-PROC 


ABBC 

COJOIN 

ADDD 

COINCLUD 

ARDh 

UPDATE 


SELECT 


COPY SET 

SATELLITE 

STATE 


FIRST 

PLACE 


LESS FIRST 
PLACE 


YSATST XSATST LSETPL 1 LSETPL LSETPL 2 LSETPL 

SSETIM 
csrsiM 
LSETPL 1 ' 

LSETPL 2 


XSATST 

> 

DA 

STATE OF 

SATELLITES 

-DATA TYPE — PART OF 
STATE 

YSATST 

> 

STATE OF 

SATELLITES 

STATE 

SSETIM 

> 

ORDERED 

SETS OF IMAGES 

ORDSFT 

LSETPL 

> 

ORDERED 

SETS OF PLACES 

ORDSET 

CSTSIM 

> 

ORDERED 

SETS OF (ORDERED SETS OF IMAGES) 

ORDSET 

LSETPL 

2 > 

ORDERED 

SET OF PLACES 2 

ORDSET 

LSETPL 

j > 

ORDERED 

SET OF PLACES 1 

ORDSET 


CONDITION 

0=PR0C ■ > EQUAL (Of PROCEED) 


A> 
















TYPICAL PROfiPTED SCENARIO 


HOW MAN/ OFFSPRING MG YOU WAN! TO AI.iD? 2 
FOR NODE ABDCA 
FN NAME (0 ): AUIOCOR- 

□P NAME (8 ) : ^ 

LONG NAME (10 ): AUIOMAIIC- 
LONG NAME (10 ): CGRLELAIIQ 

LONG NAME (10 )1 x 

CONNECTOR (8 ) L _ 

INPUT(8): 2-._ 

INPUT(8) : 4 

iNPUT(8) : a 

INPUT(8) : 6 

INPUT(R) : X- , 

OUTPUT ( 8) : XSAI5I-.1 


FOR OUTPUT XSATST'P 
DATA TYPE(8): SIAIE___ 

LONG NAME(IO): SIAIE-OE-^ 

LONG NAME (10): SAIELLIIES 
LONG NAME(IO): X. 

0UTPUT(8) : x___ - 

CONDITION (8 ): 

FOR NODE ABBCB 
FN NAME (8 ): SAINACCU 

OP NAME (8 ) ; _ . 

LONG NAME (10 ): SAINAW-^ 

LONG NAME (10 ) I x 

CONNECTOR (0 ).* COJQIN..._ 
iNPUT(8) : xsAisi:: 

INPUT (8) : 4 

INPUT(8): 10..._. 

INPUT(8) : 6 

INPUT (8) : X 

0UTPUT(8) : 1. 

OUTPUKS) : 

DO YOU WANT TO MAKE ANY CHANGES TO INPUTTED 1NF0RMATI0N7N 

FILES CLOSED RUNNING UPDATE 

PASSWORD 8iHR 

UPDATE COMPLETED 



TREE DIAGRAM 


A 

SATNAV 


AA 

CHOOSE 

OPTIONS 


ABA 

CLONEd ) 

COPY or 

STATE 


• 

:abba 

L . . ^ ^ 

:copY 

SET 

:less 

FIRST 

(PLACE 

• 

# 

• 

• 



1 

1 

ABB 

1 

1 

ABBB 

— 

1 

PERFORM 

1 

SELECT 

AB 

- -- 

AUTOMATIC 

— 

FIRST 

PERFORM 

1 

PROCESSING 

1 

PLACE 

SATNAV 

— ! 

FUNCTIONS 

I 


FUNCTIONS 

1 


1 



;abbc 

: UPDATE 

(SATELLITE 

(STATE 


(ABC 

(EXECUTE 

(MANUAL 

(OVERRIDE 


ABCA 

OVERRIDE 


ABCB 

SATNAV 
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APPLICATION OF SOFTWARE TECHNOLOGY TO A FUTURE 
SPACECRAFT COMPUTER DESIGN 

Robert J. LaBaugh 
Martin Marietta Corporation 
Denver, Colorado 

An Independent Research and Development task* at Martin Marietta 
has been investigating advanced spacecraft computer systems for the past 
couple of years. The task objectives are to demonstrate how major im- 
provements in spacecraft computer systems can be obtained from recent 
advances in hardware** and software technology. This presentation 
covers the major software topics which have been addressed during the 
task. 

Investigations into integrated circuit technology performed at the 
beginning of the task indicated that the CMOS/SOS chip set being develop- 
ed for the Air Force Avionics Laboratory at Wright Patterson had the best 
potential for improving the performance of spaceborne computer systems. 

An integral part of the chip set is the bit slice arithmetic and logic 
unit (ALU). The flexibility allowed by microprogramming, combined with 
the software investigations described below, led to the specification of 
a baseline architecture and instruction set. 

*This work was conducted by the Denver Division of Martin Marietta Cor- 
poration under Independent Research and Development Project Authorization 
D-80D. 

**Related paper, "Application of Advanced Electronics to a Future Space- 
craft Computer Design", in Microprocessor Hardware Technology Session. 
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One of the goals was to design an instruction set similar to modern 
minicomputer instruction sets, with multiple user registers. Another goal 
was to provide the throughput and precision required for flight applications, 
and at the same time provide an instruction set which would ease the pro- 
gramming of such applications. Several assembly language application pro- 
grams, along with the necessary microcode, were written to help define the 
features to be included in the processor design. One of the areas this 
was used for was determining the number of registers in the system. An 
increase in the number of floating point registers from four to eight pro- 
vided around a 10% improvement in execution time for one of the application 
programs. The number of registers was limited, however, by a desire to 
store them in the 16 physical registers internal to the ALUs. This would 
avoid delays in accessing the registers and help keep the parts count down. 

The need for scratch registers by some of the microprograms was another 
limiting factor. As a compromise between having as many registers as 
possible and the limits imposed by the ALUs, it was decided there should 
be seven floating point registers and eight general purpose registers. 

Partly to accommodate all the user registers desired, the system was designed 
to have two arithmetic processing units: one to handle floating point oper- 

ations and store the floating point registers; and the other to handle general 
purpose registers, and system registers such as stack pointers and the pro- 
gram counter. Only one of the two processors is active at any given time. 
Which processor is active during a cycle is determined by means of a bit 
in the microword. This was done so that the processors could share the 26 
bits in the microword needed for ALU control. 

The precision and format of floating point operands was derived in 

, . ■ r 

part from the results of a study on high precision attitude computations. 

The main goal of the study was to characterize the drift rate of the in- 
tegrator as a function of operand precision and rate sampling interval. 

One of the conclusions was that 32 bit -floating point operands, with 24 
bit mantissas, were adequate for currently envisioned projects. The study 
was based on data using operands with binary normalization. To remain con- 
sistent with this, we decided to use binary rather than hex normalization 
which can result in only 21 bits of significance in a 24 bit mantissa. 
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Because of the characteristics of the chip set and a desire for fairly 
high performance, a horizontal, rather than vertical, microword was used. 
There are 34 fields in the microword, which is 80 bits wide. As wide as 
the microword is, a fair number of fields still have to be decoded. En- 
coded fields are primarily used for things like selection of operand source 
and destination, the source for register specifications, and condition code 
selection. A wide microword, however, puts constraints on the number of 
words of control store because of the high non-recurring cost of ROMs. In 
an effort to keep the size of the control store within limits, and to assure 
adequate system performance, the microcode was developed concurrently with 
the circuit design. This allowed us to make various hardware versus soft- 
ware trades at a time when changes to the hardware design could be accomp- 
lished without too much difficulty. 

Fairly early in the task an absolute assembler and an instruction set 
simulator were developed. These allowed the software development to pro- 
ceed while the hardware design was being completed, and the hardware was 
being built. Langley Research Center has recently provided Pascal and HAL 
compiler frontends. The Pascal system includes a compiler which produces 
P-code, and a P-code interpreter. The HAL system consists of a compiler 
which produces HALMAT, a program which translates HALMAT into H-code, and 
an H-code interpreter. H-code is P-code with a few extra instructions and 
an expanded run time library. A. program to translate from P-code/H-code to 
assembly language has been developed and Pascal and HAL routines have been 
executed on the instruction set simulator. The translator has undergone 
several refinements to improve the code generated. The initial version 

mimicked P-code fairly closely by keeping the expression evaluation stack 

« 

in memory. By redefining register usage so that the top of the stack was 
kept in registers wherever possible, a 50% improvement in memory usage and 
execution time was achieved. Floating point push and pop instructions were 
also added. An investigation of a one instruction lookahead in the trans- 
lation process indicated a further 12 to 14 percent improvement in memory 
usage and 7 to 30 percent improvement in execution time was possible. 

Future plans include continued investigation of P-code instruction look- 
ahead in the translation process and further examination of the impact of 
high order languages on the instruction set. 
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BACKGROUND 

OBJECTIVES:* 

QUANTITATIVELY DETERMINE HOW RECENT ADVANCEMENTS IN HARDWARE** AND 
SOFTWARE TECHNOLOGY CAN BE USED TO OBTAIN IMPROVEMENTS IN SPACECRAFT 
COMPUTER CAPABILITIES. 

CMOS/SOS INTEGRATED CIRCUITS 
SEMI-CUSTOM LSI DEVICES 
LEADLESS CARRIER PACKAGING 
MICROPROGRAMMING 

PASCAL. HAL. ADA. HIGHER ORDER LANGUAGE 

*THIS WORK WAS CONDUCTED BY THE DENVER DIVISION UNDER INDEPENDENT 
RESEARCH AND DEVELOPMENT PROJECT AUTHORIZATION D-80D 
**RELATED PRESENTATION. "APPLICATION OF ADVANCED ELECTRONICS TO A FUTURE 
SPACECRAFT COMPUTER DESIGN". IN SESSION IV: MICROPROCESSOR HARDWARE 
TECHNOLOGY 


APPROACH 


PRELIMINARY REQUIREMENTS AND IMPACT 

S/W TO ASSIST IN ARCHITECTURE DESIGN 
t ABSOLUTE ASSEMBLER 
• INSTRUCTION SET SIMULATOR 

MICROPROGRAM DESIGN 

S/W DEVELOPMENT TOOLS 
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FEATURES- REQUIRED IN PROCESSOR 


MINICOMPUTER LIKE INSTRUCTION SET 

MULTIPLE FLOATING POINT AND GENERAL 
PURPOSE REGISTERS 

FLIGHT APPLICATIONS 

• SUFFICIENT THROUGHPUT 

• SUFFICIENT PRECISION 

• EASE OF PROGRAMMING 


REGISTER CONSIDERAIONS 


TYPES: 

• GENERAL FOR USER 

• FLOATING POINT FOR USER 

• SYSTEM FOR USER 

• SYSTEM FOR MICROPROGRAMS 

CONSTRAINTS: 

f 16 PHYSICAL REGISTERS INTERNAL TO ARITHMETIC 
AND LOGIC UNIT DEVICES 

• SEPERATE ALU DEVICES FOR FLOATING POINT 

TRADES; 

• PERFORMANCE SENSITIVITY TO SIZE OF REGISTER FILE 
0 EXTERNAL REGISTER FILE - DEGRADES PERFORMANCE 
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REGISTER CONSIDERATIONS 


OPERAND PRECISION: 

• LARGER OPERANDS REQUIRE MORE PARTS. 

LONGER CYCLE TIMES 

t MICROCODE VS HARDWARE - SLOWER. 

LARGER CONTROL STORE NEEDED 

• FLOATING POINT PRECISION - 32 BITS WITH 
BINARY NORMALIZATION SUPPORTED BY SPECIALIZED 
HARDWARE 

• INTEGER PRECISION - 16 BIT WITH 32 BIT 
PERFORMED BY MICROCODE 


FUNCTIONAL REGISTER UTILIZATION 


16 BJTS 

PROG ^A_M_ COUNTER 
USER STACK P O INTER 
PR IV STACK POINTER 


GEN 

REG 

0 

GEN 

REG 

1 

GEN 

REG 

2 

GEN 

REG 

3 



REG 

4 

GEN 

REG 

5 

GEN 

REG 

6 

GEN 

REG 

7 


32 BITS 


FLOATING 

POINT 

REGISTER 

1 

FLOATING 

POINT 

REGISTER 

2 

FLOATING 

POINT 

REGISTER 

3 

FLOATING 

POINT 

REG I STER 

4 

FLOATING 

POINT 

REGISTER 

5 

FLOATING 

POINT 

REGISTER 

6 

FLOATING 

POINT 

REGISTER 



Notes: 

• FLOATING POINT SIGN BIT KEPT IN UNIQUE 
REGISTER FILE 

t 5 OTHER 16-BIT REGISTERS RESERVED FOR 
MICROPROGRAMMER 

t 1 OTHER 32 -BIT REGISTER RESERVED FOR 
MICROPROGRAMMER 

• GENERAL REGISTERS 1-7 CAN BE USED AS 
INDEX REGISTERS 
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EXAMPLE OF PHYSICAL REGISTER UTILIZATION 


FLOATING POINT PROCESSOR 


0 

SCRATCH 1 

1 

FLT 

PT 

REG 

1 

MANTISSA 

2 

FLT 

PT 

REG 

2 

MANTISSA 

3 

FLT 

PT 

REG 

3 

MANTISSA 

4 

FLT 

PT 

REG 

4 

MANTISSA 

5 

FLT 

PT 

REG 

5 

MANTISSA 

6 

FLT 

PT 

REG 

6 

MANTISSA 

7 

FLT 

PT 

REG 

7 

MANTISSA 

8 



SCRATCH 

9 

FLT 

PT 

REG 

1 

EXPONENT 

A 

FLT 

_PT_ 

REG 

2 

EXPONENT 

B 

fJiL 

PT 

REG 

3 

EXPONENT 


FLT 

._PL 

REG 

4 

EXPONENT 

D ; 

FLT 

PT 

REG 

5 

EXPONENT 

E 1 

1 

flt" 

PT 

REG 

6 

EXPONENT 

F 

FLT 

PT 

REG 

7 

EXPONENT 


24 BITS 



The floating point sign bit file is 

EMBEDDED IN CUSTOMIZED LOGIC 


MACRO LEVEL INSTRUCTION SET 


106 INSTRUCTIONS 
8 CATAGORIES 

FIXED POINT 

index/counter register 

FLOATING POINT 

LOGICAL 

BRANCH 

STACK AND REGISTER SAVE AND RESTORE 
executive FUNCTIONS 
MISCELLANEOUS 


10 FORMATS 

REGISTER-REGISTER 

REGISTER 

REGISTER-ADDRESS 

REGISTER-IMMEDIATE 

INDEX-REGISTER 


INDEX EXTENDED 
ADDRESS 
INDEX-ADDRESS 
SPECIAL 

SPECIAL EXTENDED 
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MICROPROGRAM DESIGN 


HORIZONTAL RATHER THAN VERTICAL 

• DECODING FIELDS DEGRADES PERFORMANCE 

• FORCE LOGIC TO QUIESCENT STATE WHEN 
NOT BEING USED 

t BECAUSE OF WIDE MICROWORD, NEED TO KEEP 
NUMBER OF WORDS OF CONTROL STORE AS SMALL 
AS POSSIBLE 

MICROPROGRAMS DEVELOPED CONCURRENTLY WITH HARDWARE DESIGN 

• ASSURE ADEQUATE PERFORMANCE 

• CONTROL STORE LIMITED BECAUSE OF HIGH NON- 
RECURRING COST 


PRIMARY SOFTWARE MODULES & STATUS 

REQMTS 

DESIGN 

IMPLEMENTATION 

ASMA-D32: 

ABSOLUTE ASSEMBLER 

COMPLETE 

COMPLETE 

COMPLETE 

ASMR-D32: 

RELOCATABLE ASSEMBLER 

COMPLETE 

COMPLETE 

COMPLETE 

LNK-D32: 

LINK EDITOR 

COMPLETE 

COMPLETE 

COMPLETE 

SIM-D32: 

INSTRUCTION SET SIMULATOR 

. COMPLETE 

COMPLETE 

COMPLETE 

PAS-LCl: 

PASCAL COMPILER 

COMPLETE 

COMPLETE 

COMPLETE 

HAL-LCl: 

HAL COMPILER 

COMPLETE 

COMPLETE 

COMPLETE 

RTEX: 

REAL TIME EXECUTIVE 

IN PROGRESS 

1981 

1981 

SSP-D32: 

SCIENTIFIC SUBROUTINE PACKACjE 

IN PROGRESS 

IN PROGRESS 

IN PROGRESS 

STD-2: 

SELF TEST/DIAGNOSTIC ROUTINES 

IN PROGRESS 

IN PROGRESS 

1981 . 
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PASCAL AND HAL COMPILERS 

• FROM LANGLEY RESEARCH CENTER 

• WRITTEN IN PASCAL 

PATH PASCAL COMPILATION PROCESS 

• PRODUCES P-CODE 

• INTERPRETER FOR P-CODE 

HAL COMPILATION PROCESS 

• PHASE 1 PRODUCES HALMAT 

• HALMAT TO H-CODE 

• INTERPRETER FOR H-CODE 

TRANSLATOR FROM P-CODE/H-CODE TO ASSEMBLY LANGUAGE 
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SOFTWARE PRODUCTS 



TRANSLATOR REFINEMENTS 


SAMPLE PROGRAMS 

• CALCULATE PI TO SIX DIGITS 

• BINARY SEARCH 

PRELIMINARY DESIGN: 

• STACK IN MEMORY 

FIRST REVISION: 

• TOP OF STACK KEPT IN REGISTERS 

• FLOATING POINT PUSH AND POP ADDED 

SECOND REVISION: . 

• LOOK AT TWO P-CODE INSTRUCTIONS 
BEFORE GENERATING CODE 
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PROCESSOR SOFTWARE COMPARISON 


NUMERIC TEST PROGRAM - PI APPROXIMATION 



MAC-16 

PDP 11/3DM 

ATAC-16 

ASSEMBLY LANGUAGE 




LINES OF CODE 

DO 

37 

50 

WORDS OF MEMORY 

7M 

68 

79 

EXECUTION TIME 

11969 

1D909 

12D12 

PASCAL LANGUAGE 




LINES OF CODE 

28 

28 

- 

WORDS OF MEMORY 

2D3 

3D7 

- 

EXECUTION TIME 

16691 

■ - 

— 

HAL LANGUAGE 




LINES OF CODE 

28 


28 

WORDS OF MEMORY 

25D 


157 

EXECUTION TIME 

16885 

- 

13722 


PROCESSOR SOFTWARE COMPARISON 


NON-NUMERIC TEST PROGRAM - 

BINARY SEARCH 
MAC-16 

PDP 11/3DM 

ATAC-16 

ASSEMBLY LANGUAGE 

LINES OF CODE 

25 

26 

2D 

WORDS OF MEMORY 

31 

31 

2D 

EXECUTION TIME 

1D3 

170 

127 

PASCAL LANGUAGE 

LINES OF CODE 

17 

17 

- 

WORDS OF MEMORY 

138 

107 

- 

EXECUTION TIME 

886 


- 

HAL LANGUAGE 
LINES OF CODE 

17 


17 

WORDS OF MEMORY 

1D2 


65 

EXECUTION TIME 

937 


665 





CODE GENERATOR IMPROVEnENT HISTORY 


WORDS OF 



EXECUTION 



o BINARY SEARCH 
^ PI APPROXIMATION 


FUTURE PLANS 


TRANSLATOR: 

• MULTI P-CODE INSTRUCTION LOOKAHEAD 

• MULTI PASS - OPTIMIZE REGISTER USAGE 

DIRECT HALMAT TO ASSEMBLY LANGUAGE CONVERSION 
BASED ON HALMAT TO H-CODE PROGRAM 

CONTINUE EXAMINING HOL IMPACT ON INSTRUCTION SET 
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A TRANSLATOR WRITING SYSTEM FOR 
MICROCOMPUTER HIGH-LEVEL LANGUAGES AND ASSEMBLERS 

W. Robert Collins* 

Computer Sciences Corporation 
Hampton, Virginia 

' John C. Knight 
Langley Research Center 
Hampton, Virginia 

and 

Robert E. Noonan** 

College of William and Mary 
Williamsburg, Virginia 


NASA LaRC uses many dedicated microprocessors in aerospace research. Few 
software tools are available for these machines, and in particular, very few have 
any form of high-level language facility. Since the Langley environment Involves 
considerable experimentation, a great deal of software is experimental and may 
change frequently. It has to be prepared relatively quickly and at low cost. 

In order to implement high-level languages whenever possible, a Translator 
Writing System of advanced design has been developed. It is Intended for routine 
production use by many programmers working on different projects. As well as a 
fairly conventional parser generator, it includes a system for the rapid generation 
of table driven code generators. This code generation system is the result of 
research performed at the College of William and Mary under NASA sponsorship. The 
parser generator was developed from a prototype version written at the College of 
William and Mary. 

The Translator Writing System includes various tools for the management of the 
source text of a compiler under construction. In addition, it supplies various 
"default” source code sections so that its output is always compilable and 
executable. The system thereby encourages iterative enhancement as a development 
methodology by ensuring an executable program from the earliest stages of a compiler 
development project. 

This presentation will describe the Translator Writing System and some of its 
applications. These include the PASCAL/48 compiler, three assemblers, and two 
compilers for a subset of HAL/S. PASCAL/48 is a Pascal-like language for the 
Intel-8748 microcomputer. The assemblers which have been built are for assembly 
language subsets for the Intel-8080, the Motorola M68000, and the NSSC-II. The 
HAL/S subset was implemented for the Intel-8080 and the GE 703. Detailed measure- 
ments of the use of the system to build the code generators for the HAL/S compilers 
will be given. 


*Work performed under NASA contract numbers NASl-14900 and NASl-16078. 

**Work performed under NASA grant number NSG- 1435. 
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THE PROBLEM 


. NEED HIGH-LEVEL LANGUAGES, HENCE COMPILfRS 
. NEED ASSEMBLERS 
. ONE SOLUTION IS A 7WS 

TWS CRITERIA 

. ENCOURAGE ITERATIVE ENHANCEMENT 

- EARLIEST POSSIBLE EXECUTION 

- TEXT MANAGEMENT TO RELIEVE TEDIUM 

. FLEXIBILITY IN ITS USE 
. TRANSPORTABLE IMPLEMENTATION 


TRANSLATOR WRITING SYSTEM 



Old Compiler Old Compiler Old Compiler 

I . A . I 
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USE OF TWS 


1. IF PARSER NEEDED, RUN PARGEN, EXECUTE RESULTING COMPILER TO TEST. 

2. CHANGE GRAMMAR AS NECESSARY, RERUN PARGEN. 

3. ADD SE/VIANTICS USING EDITOR. 

4. RECOVER GRAMMAR AND SEA/IANTICS WITH GRAMGEN IF NECESSARY TO RERUN 
PARGEN. 

5. IF CODE GENERATION NEEDED, PREPARE CGGL SPECIFICATION AND RUN CODGEN. 

6. MODIFY CGGL AS NEEDED. 

7. ITERATE THROUGH ABOVE STEPS ADDING LANGUAGE FEATURES AS DESIRED. 

PARGEN 

. INPUTS 

- GRAMMAR IN STANDARD BNF 

- SEMANTICS IN PASCAL 

- SKELETON OR OLD COMPILER 

. OUTPUT IS AN EXECUTABLE COMPILER INCLUDING 

- SCANNER 

- LALR (1) PARSER 

- SEMANTICS ROUTINE 

• TEXT MANAGER PRESERVES PROGRAMMER'S CONTRIBUTION TO COMPILER 
E, G. , SYMBOL TABLE ROUTINES , 
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CODGEN 


INPUTS 


- CGGL SPECIFICATION 

- SKELETON OR OLD COMPILER 


OUTPUT IS AN EXECUTABLf COMPILER INCLUDING A CODE GENERATOR. 

I 


CGGL IS A NON-PROCEDURAL LANGUAGE FOR DESCRIBING THE CODE- 
GENERATION PROCESS. 


TEXT MANAGER PRESERVES PROGRAMMER'S CONTRIBUTION TO COMPILER 
E.G., MACHINE LANGUAGE FORMATTER. 


PASCAL/48 


• INTEL-8748 

- MICROCOMPUTER 

- 8-BIT CPU 

- 64 WORD RAM 

- 1024 WORD ROM 

- 27 I/O LINES 

• PASCAL/48 

- PASCAL DERIVATIVE FOR 8748 

- EXTENSIONS TO ALLOW CONTROL OVER GENERATED CODE 

- RESTRICTIONS TO PROHIBIT INEFFICIENT FD\TURES 

- COMPILER AVAILABLE ON CDC CYBERS 



ASSEMBLERS 


• CUSTOMIZED SKELETON FOR ASSEMBLERS 

- TWO PASSES 

- STANDARD LISTING BY DEFAULT 

- FLEXIBLE INPUT FOR/VIAT CONVENTIONS 

- HANDLES MACROS WITHOUT PARAMETERS 

• COMPARED TO META -ASSEMBLER, ASSEMBLER BUILT FOR NSSC-II 

- WAS PRODUCED MORE QUICKLY 

- EXECUTES 5 TIMES FASTER 

- USES ONE FOURTH THE SPACE 


EXAMPLE PASCAU48 PROGRAM 


NASA/ LANGLEY RESEARCH CENTER 80/0B/26. 08.91.12. PAGE 1 

PASCAL 87^8C VERSION l.C.O PROGRAM MAIN CSC/NASA 


1 PROGRAM F0R_Y0U5 

2 


3 

VAR IC2] t INTEGERi 



il 

AC16.300# POM] t ARRAY 

[100] 

OF INTEGER; 

6 

7 

VALUE A - (99 OF 0# 1); 



e 

9 

PROCEDURE GET^INPUT; 



xo 

BEGIN 



11 

REPEAT 



12 

UNTIL POPTl BIT 3 



13 

END; (♦ GET.INPUT ♦) 



1^ 




15 




16 

BEGIN (♦ PROGRAM FOR.YOU ♦) 



17 

FOR 1 100 DOWNTO 1 DO 



16 

BEGIN 



19 

GET. INPUT; 



20 

PORTl «• PORTl AND 2.11100011) 


21 

P0RT2 «• ACn ♦ PORTl XOR I 



22 

END (A FOR 1 !• 100 DOWNTO 

1 DO 

BEGIN 

23 

END. (« PROGRAM FOR.YOU *) 





GENERATED CODE FOR EXAMPLE PROGRAM 



jhP 

L009 





NOP 





L003t 

JHP 

LOC3 





NOP 






NOP 





LOOT* 

JHP 

LOOT 




L009* 

CLR 

A 





hOV 

PSW« A 





JMP 

L012 




LOOPS 

IN 

A, PI 

f 

LINE 

9 


CPL 

A 

$ 

LINE 

13 


JB3 

LOOO 


LINE 

13 


RET 


; 

LINE 

13 

L012I 

MOV 

P2/#99 

} 

LINE 

lA 

L0X4S 

CALL 

LOGO 

9 

LINE 

18 


ANL 

P1#«22T 

5 

LINE 

21 


IN 

A, PI 

; 

LINE 

22 


MOV 

R1>A 

f 

LINE 

22 


MOV 

A,P2 

i 

LINE 

22 


MOVP3 


i 

LINE 

22 


ADD 

A#R1 

5 

LINE 

22 


XRL 

A,R2 

I 

LINE 

22 


OUTL 

P2#A 

9 

LINE 

22 


DJNZ 

R2>LC1^ 

1 

LINE 

22 


Separate Code Generation 
USING CG6L 


Language: HAL/S 

Intermediate Code Language: HALMAT 

178 OPERATORS TOTAL 

30 OPERATORS IMPLEMENTED 

25 GENERATE CODE 

BASICALLY AN INTEGER SUBSET WITH SIMPLE CONTROL 

STRUCTURES 

Code Generators 

ONE PASS 

NO PRE-OPTIMIZATION PASS 

NO PEEPHOLE OPTIMIZATION 

Intel 8080, 6E 703 
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Implementations 


Intel 8080 

8. BIT MACHINE 

SIHGLE ACCUMULATOR 

NO INDEX REGISTER 

1/ Is 3 BYTE INSTRUCTIONS 

HARDWARE STACK 

ONLY INTEGER ADD^ SUBTRACT 

16 BIT ADDRESSES 

6E 703 

16 BIT MACHINE 

SINGLE ACCUMULATION 

INDEX REGISTER 

ONE WORD INSTRUCTIONS 

NO HARDWARE STACK 

INTEGER ADD, SUBTRACT, MULTIPLY, DIVIDE 

ONLY ADDRESS CURRENT PAGE, PAGE ZERO 

PAGE: 256 WORDS 


703 Code Generator 

Ja^ • Time (days). 

Reading manual .5 

C66L PROGRAM 1.5 

Writing Pascal ROUTINES 1.5 

Debugging . 1.0 


4.5 DAYS 


Notes : 

1. All PROGRAMS WERE CODED AND KEYED BY'HoONAN. 

2. Some of debugging time was used in cleanup. 

3. One debugging run was used to fix a bug introduced by 

CLEANUP. 

4. A total of 6 RUNS (execution) were used. 

5. One CG6L bug. 


185 



1 


703 Implementation 


Source of 
Code 

No. 

Procedures .. 

% 

Lines . 

% Instr 
Storage 

8080 Imple, 

46 

58% 

58% 

Modified 8080 

4 

8% 

6% 

Noonan 

9 

10% 

10% 

C66L 

1 

24% 

26% 


Notes: 

1. CG6L PROGRAM; 292 lines 

2. Pascal PROGRAM: 890 lines 

3. For an earlier non-table-driven implementation, C66L 
ACCOUNTED FOR 835S OF LINES AND 771 OF STORAGE, 
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SESSION IV 

MICROPROCESSOR HARDWARE 
TECHNOLOGY 



25 


A HIGH PERFORMANCE MULTIPLIER PROCESSOR 
FOR USE WITH AEROSPACE MICROCOMPUTERS 

P. E. Pierce 

Sandia National Laboratories 
Albuquerque, New Mexico 


An MC68000-based microcomputer including a hardware multiplier 
processor has been designed and prototyped for a re-entry 
vehicle navigation and control application. In this paper, 
the microcomputer is discussed with emphasis on the multiplier 
processor architecture, software control and theory of operation. 

The MC68000 CPU of the microcomputer cannot satisfy the real- 
time multiply processing requirements of a high accuracy RV 
navigator. The standalone CPU thru-put for multiply intensive 
applications is increased approximately seven times by the 
addition of a board level Hardware Multiplier Processor (HMP) . 
Although the HMP was designed for the MC68000 microcomputer, 
it can be used with any 16 or 32 bit CPU with minimal 
modifications. 

The memory mapped HMP performs 16 and 32 bit multiplications 
and can optionally add or subtract the full product to previous 
accumulator contents. The circuitry is sufficiently fast to 
allow the MC68000 running at 8 MHz to write single or double 
precision variables to the HMP using memory to memory transfers 
and perform an operation with no wait states introduced or 
overhead time for command passing. 

The result of multiply and accumulate operations may be 
transferred in its entirety or scaled by 2^30 and rounded 
automatically prior to transfer to the destination location 
specified by the CPU. Worst case CPU wait times introduced 
are: 3.3 ysec for double precision scale by 2"^^ and round 

to single precision; and 6.3 ysec for quadruple precision scale 
by 2~30 and round to double precision. 

i 

The Hardware Multiplier Processor incorporates Serial/Parallel 
Hardware Multiplier ICs, a translation PROM and address con- 
trolled logic to implement previously mentioned arithmetic 
functions. The use of serial arithmetic circuitry yields a 
processor of small physical size, low power and significant 
flexibility. The computation time of the HMP is shorter than 
most of the general memory addressing modes of the host CPU. 

The nine least significant CPU address bits in conjunction 
with the translation PROM control all HMP functions. The 
translation PROM provides the function related serial clock 
count to the clock control logic which in turn controls all 
HMP timing. 


Preceding Page Blank 
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SANDIA AEROSPACE COMPUTER VERSION A 
CSANDAC IV) 


ARCHITECTURE 
MC68000 CPU 

32 BIT DATA AND ADDRESS REGISTERS 
56 INSTRUCTIONS 
lA ADDRESSING MODES 
MEMORY MAPPED I/O 
16 BIT DATA BUS 
16 M BYTE ADDRESS SPACE 
HARDWARE MULTIPLIER PROCESSOR (HMP) 
VECTORED INTERRUPTS 

POWER REQUIREMENTS 
+5V 3 3A TYPICAL 

PHYSICAL 

EXPANDABLE MODULAR CONSTRUCTION 
STACKABLE PIN- SOCKET INTERMODULE BUS 
17.8 CM X 15.9 CM x 1.27 CM MODULES 


SANDAC IV CPU MODULE 


MC68000 CPU 

16K BYTE EPROM MEMORY 

16K BYTE NON-VOLATILE CMOS RAM 

POWER MONITOR & RESET CIRCUIT 


SANDAC IV I/O MODULE 


A CHANNEL OPTO- ISOLATED USART SERIAL I/O 
8 CHANNEL PRIORITY INTERRUPT CONTROLLER 
5 CHANNEL PROGRAMMABLE 16 BIT TIMER/COUNTER 
16 BIT MEMORY MAPPED (AK WORD) I/O 



SANDAC IV HMP MODULE 


MEMORY MAPPED REGISTERS AND FUNCTIONS 

SINGLE PRECISION (16 BIT) AND DOUBLE PRECISION 
(32 BIT) FUNCTIONS 

MULTIPLY WITH OPTIONAL ADD OR SUBTRACT TO PREVIOUS 
ACCUMULATOR CONTENTS 

SCALE 2-^ AND ROUND 

OVERFLOW DETECTION RELATING TO ACCUMULATION 
ADDRESSING ERROR DETECTION 

CONTROL FUNCTIONS DERIVED FROM LATCHED ADDRESS BITS 
HOST CPU ALLOWED TO PROCEED IN PARALLEL WITH HMP 
AUTOMATIC HOLD-OFF OF HOST CPU IF HMP BUSY 


HARDWARE M JLTIPLIER PROCESSOR 
BTX)CK DIAGRAM 



DP ROD 


















HARDWARE MULTIPLIER PROCESSOR 
CONTROL BLOCK DIAGRAM 


FUNCTION 



EXAMPLE HMP ADDRESS MAPPED FUNCTIONS 


ADDRESS 




(HEX) 

FUNCTION 


t 

FEOO 

READ-CLEAR STATUS REGISTER 


FE02 

READ/WRITE PA 



FEOA 

READ/WRITE P3 



FE06 

READ/WRITE P2 



FE08 

READ/WRITE PI 



FEOA 

READ/WRITE MA 



FEOC 

READ/WRITE M3 



FEOE 

WRITE M2 



FEOE 

READ STATUS REGISTER 



FEIE 

WRITE M2. S.P. MULTIPLY 

8 ADD 


FE3E 

WRITE M2. CLEAR ACCUM.. 

S.P. MULT. 

8 ADD 

FE5E 

. WRITE M2. S.P. MULTIPLY 

8 SUBTRACT 


FE7E 

WRITE M2. CLEAR ACCUM.. 

S.P. MULT. 

8 SUB. 

FE8E 

WRITE M2 



FE90 

. WRITE Ml. D.P. MULTIPLY 

8 ADD 








EXAMPLE HMP ADDRESS MAPPED FUNCTIONS 


FUNCTION 

D.P. P REG X & S.P.. ROUND 

I 

\ 

I 

I 

D.P. P REG X 2'^ & S.P. ROUND 

D.P. P REG X 2° & S.P. ROUND 

D.P. P REG X 2^ & S.P. ROUND 

! 

I 

I 

D.P. P REG X 2^^ & S.P. ROUND 

Q.P. P REG X 2'^0 & D.P. ROUND 
\ 

* I 

I 
I 

Q.P. P REG X 2'^ g D.P. ROUND 
Q.P. P REG X 2° g D.P. ROUND 
Q.P. P REG X 2^ g D.P. ROUND 

I 

I 

1 

I 

Q.P. P REG X 2^° g D.P. ROUND 


FUNCTION EXECUTION TI.ME 


FUNCTION EXECUTION TIME 

S.P. MULTIPLY g ACCUMULATE 2.38 //s 
D.P. MULTIPLY g ACCUMULATE A.38 ^s 
D.P. SCALE 2“^^ g S.P. ROUND 3.31 uS 
D.P. SCALE 2° g S.P. ROUND 2.4A uS 
D.P. SCALE 2^^ g S.P. ROUND 1.56 ns 
Q.P. SCALE 2'^Q g D.P. ROUND 6.31 ns 
Q.P. SCALE 2^^ g D.P. ROUND A.AA //s 
Q.P. SCALE 2^0 g D.P. ROUND 2.56 ms 


ADDRESS 

CHEX) 

FFOO 

I 

I 

I 

FFIA 

FFIC 

FFIE 

I 

I 

j 

FF38 

FF80 

\ 

I 

I 

FFBA 

FFBC 

FFBE 

1 

I 

FFF8 


191 



SANDAC IV BENCHMARK EQUATION 
^ir 

NOTE; ALL TERMS ARE 32 BIT FIXED POINT, 
CONFIGURATION ' EXECUTION TIME 


MC68000 CPU a 8 MHZ 235 fjis 

(SUBROUTINE SOLUTION) 

MC68000 CPU a 8 MHZ + HMP 31 (is 

CHMP SOLUTION) 
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BENCHMARK EQUATION MACRO INSTRUCTION SOLUTION 


''ll ■ ^ll'^ll 

+ B]2C21 + B13C32 + K 

SOURCE CODE: 

LQPP K 

/LOAD Q.P. CONSTANT 

DPMA ^22 

/D.P. MULTIPLY & ADD 

DPMA 622^ ^21 

/D.P. MULTIPLY & ADD 

1 DPMA B23. C32 

/D.P. MULTIPLY & ADD 

DPSRM 6. A22 

/QUAD P. SCALE. ROUND & MOVE 
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BENCHMARK EQUATION MACRO EXPANSION 


. ^11 ■ ^ 11*^11 ^ 12 ^ 13*^31 

ASSEMBLER EXPANSION: 

MC68000 


MACRO 

MNEMONICS 

COMMENT 

LQPP m, K 

MOVE.L 

MOVE.L 

0, FE02 
K. FE06 

/LOAD Q.P. CONSTANT 

DPMA III, Cj 2 

MOVE.L 

MOVE.L 

111' 

^ll. 

FEOA 

FE 8 E 

/D.P. MULTIPLY & ADD 

DPMA 

MOVE.L 

MOVE.L 

^]2' 

C 21 . 

FEOA 

FE 8 E 

/D.P. MULTIPLY & ADD 

DPMA Bi 3 > C 32 

MOVE.L 

MOVE.L 

C 31 . 

FEOA 

FE 8 E 

/D.P. MULTIPLY 8 ADD 

DPSRM 0. ^ll 

MOVE.L 

FFBC, 

All 

/QUAD P. SCALE. ROUND 8 MOVE 


SUMMARY 

EFFECTIVELY EXPANDS HOST CPU INSTRUCTION SET 

EASY INCORPORATION INTO ANY 16 BIT SYSTEM 

HIGH PERFORMANCE DUE TO SIMULTANEOUS DATA & COMMAND 
TRANSFER BY HOST CPU 

SERIAL ARITHMETIC APPROACH REDUCES COMPONENT COUNT 

■ EQUATION EXECUTION TIME PRIMARILY DEPENDENT ON CPU 
MEMORY ACCESS TIME 

. STRAIGHT FORWARD SOFTWARE CONTROL 

SINGLE |iP CPU PLUS fIMP PROVIDES PERFORMANCE COMPARABLE 
TO BIPOLAR BIT-SLICE DESIGNS 
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APPLICATION OF ADVANCED ELECTRONICS TO A FUTURE 
SPACECRAFT COMPUTER DESIGN 

Philip C. Carney 
Martin Marietta Corporation 
Denver, Colorado 

Over the past two and one half years at Martin Marietta, an Independent 
Research and Development task* has been conducting an. extensive investigation 
on advanced spacecraft computer systems. The task objectives are to 
quantitatively determine how recent advancements in hardware and , software** 
technology can be used to obtain major improvements in spacecraft computer 
system capabilities. This paper describes the major hardware aspects which 
have been investigated and what results have been obtained. 


* This work was conducted by the Denver Division of Martin Marietta 
Corporation under Independent Research and Development Project Authorization 
EH80D. 

** Related paper, "Application of Software Technology to a Future Spacecraft 
Computer Design, in Microprocessor Software Technology Session. 
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During 1978 several archi tecture trade studies were conducted to arrive at a 
deci si on on what characteristics a future spacecraft computer should have. 

The architecture trade studies went through two phases; the implementation 
independent phase and the chip set dependent phase. Some of the major factors 
which were included during the first phase were: 


o Data types and preci si on , 

o Processing throughput, 

o Input and output, 

o Address space, 

o Instruction types, 

o Multiprogramming features, and 

o Test support equipment. 


In general terms, a modern minicomputer- like architecture with a 250,000 
operations per second performance and the lowest possible power consumption 
was desired. It was noticed almost immediately that in some cases it was 
difficult to define certain architecture features because they appeared to be 
application dependent. For example, input and output (I/O) appears to vary 
depending on the spacecraft data bus. To allow for this variation but not 
impede progress it was decided to use memory mapped I/O. This approach, 
insures that sufficient flexibility is maintained in the architecture for most 
applications. In a related area a slightly different approach was taken I/O 
is normally handled in one of two ways, register transfers or direct memory 
access (DMA). If the direct memory access was imbedded in each I/O controller 
than each application, each would be burdened with the nonrecurring cost of 
DMA. To avoid this situation we incorporated a generalized Direct Memory 
Processor which can buffer and transfer data between a memory mapped I/O 
controller and main memory, Hence there is only a one time nonrecurring 
design cost associated with this feature of the coraputer. 


In 1978 integrated circuits technology was reviewed. Of particular interest 
in this area was the feasibility of using Complementary Metal Oxide 
Semiconductor/Silicon on Saphire (CMOS/SOS) parts. The primary reason for 
interest in CMOS/SOS was the favorable speed/power ratio which is important in 
spacebome applications. The candidate CMOS/SOS chip sets which were 
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investigated include: custom devices developed by NASA Marshall Space Flight 

Center and Air Force Space Division (formerly SAMSO); parts developed under 
the Space Division Advanced Computer Technology program (ACT-I); 290X parts 
under development at Raytheon; and a microprocessor chip set being developed 
at RCA under contract to the Air Force Avionics Laboratory at Wright Patterson 
(AFWAL). We elimated the use of custom parts early in our selection process 
because of their high cost. The ACT and Raytheon parts were eliminated 
because a comprehensive family of support components was not available. It 
was felt, therefore, that the best potential CMOS/SOS technology for use in 
spacebome applications was the AFWAL/RCA microprocessor chip set. In . 
addition to being a comprehensive family of LSI devices, the units are being 
produced in a radiation hardened process with high reliability screening. 
Recently the Global Positioning System (GPS) program has selected this chip 
set for use giving further evidence that our decision to base our design on 
the AFWAL/RCA chip set was appropriate. 

The LSI devices available in the RCA chip set are: the TCS 129 General 

Processing Unit (GPU), the TCS 196 Multiplier, the TCS 09X Gate Universal 
Array (GUA), the TCS 150 Random Access Memory (RAM) , the TCS 075 Read Only 
Memory, and the TCS 158 Microprogram Controller Unit. The GPU forms the 
foundation for the entire chip set. It is an eight bit wide arithmetic and 
logic slice that can be cascaded to form an arbitrarily wide data word. The 
TCS 196, unlike other multiplier chips presently available, is also a 
cascadable device. All of the partial product logic is included on the TCS 
196 to form an N x M multiplier without the need for supporting hardware 
logic. The purpose of the TCS 09X GUA is to provide the logic and circuitry 
which in most other chip set families is found in small and medium scale 
integrated circuits. These arrays are fixed regular patterns of transistors 
and routing paths. By defining transistor interconnection, the GUA is 
customized with logic in much the same way that Read Only Memory/ is customized 

with data. Some of the benefits associated with GUAs are improved speed and' 
real estate requirements; disadvantages include higher nonrecurring cost and 
greater design risk. Martin Marietta has thus far designed three Gate 
Universal Arrays and testing has shown that the devices are functionally 
correct and exceed performance expections. 


Once the first phase of the architecture analysis was completed, the factors 
associated with use of the CMOS/SOS microprocessor chip set had to be taken 
into account. Some of these factors were: 


Number of user available registers, 

High speed arithmetic support hardware, 

Instruction decoding. 

Data formatting and deformatting, 

Memory volatility, and 
Interrupt handling. 

} 

It is important to mention at this time that software* analysis as well as 
circuit analysis played a significant part at this time in determining what 
the final characteristics of the computer would be. For example the fact that 
we desired a modern minicomputer- like architecture implied that multiple 
general purpose registers were required. The number of registers however 
could only be determined by coding application programs, measuring the 
resulting throughput, and performing the physical circuit design to determine 
what the impact was in terms of hardware cost and complexity. 


o 

o 

o 

o 

o 

o 


Throughout the first half of 1979 we performed many paper emulations in which 
we wrote application programs, wrote microprograms, and prepared circuit 
layouts. These paper emulations allowed us to determine specific advantages 
and disadvantages inherent in different architectures implemented with the 
CMOS/SOS microprocessor chip set. In midyear we chose the "best" architecture 
for implementation. Best is a subjective term which in some cases such as 
performance and power consumption can be determined quantitatively, but in 
other cases such as flexibility and risk it can only be measured qualitatively 

After the selection process was completed, detailed design began with the goal 
of having an operational demonstration unit in 1980. The most challenging 
part of the detailed design was the many unknowns associated with using a 
microprocessor chip set which was still under development at that time. Our 
three primary concerns were internal device performance, off-chip drive 

* Op. Cit. 
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capability, and Gate Universal Array layout. The first concern was handled by 
derating devices a minimum of 100% using the limited test data available. 
Testing at Martin Marietta has since shown that all devices are much better 
than were originally anticipated. Our second concern, off-chip drive 
capability, was caused by the capacitance loading problems associated with 
CMOS technology. This problem becomes particularly severe in the area of the 
main memory interface. To eliminate the concern we incorporated a bulk 
hardened signal level converter to drive the memory bus at TTL levels. The 
addition of the signal level converter causes an added latency along the bus 
but this is a much better situation than that which would have occurred if an 
attempt had been made to fanout the CMOS signals. Our remaining concern, GUA 
design, was handled very conservatively. TTL circuit equivalents were built 
for each array, extensive software logic simulations were conducted, and the 
entire data submittal package was independently verified before shipment to 
RCA. As a result of this effort, no Martin Marietta caused problems have been 
found in any of the three designs which we have completed. There were some, 
issues in the testing area which arose because of Martin Marietta's and RCA's 
lack of experience with the chip set. These have since been resolved by 
modifying our software so that test vector data is automatically generated 
during the logic simulation. 

Throughout 1980 efforts have been directed toward fabrication of a breadboard 
unit which demonstrates the primary computer modules: the central processor 

module, the priority interrupt controller, the memory bus driver/receiver, and 
an 8K RAM memory bank. Additionally an operator control panel, a writable 
control store, a programmable read only memory bank, and a serial I/O port 
were implemented to facilitate development. The resulting computer has been 
operational for several months and many of the major design goals have already 
been demonstrated. Functionality, performance and power consumption meet our 
expectations. 

In 1980 concurrent with our breadboard fabrication we took the first step 
towards producing a qualified flight unit. This step was the fabrication and 
testing of mockup printed circuit boards using leadless carrier packaging 
technology. Although the Orlando Division of Martin Marietta has over three 
years experience in the use of leadless carriers, we felt it was necessary to 
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perform some specific tests to eliminate the controversy surrounding the use 
of this technology in spaceborne applications. As a result of qualification 
level thermal and vibration tests, we have found that leadless carriers 
mounted on polyimide daughter boards which are in turn properly mounted on 
larger mother boards is an appropriate packaging approach. 

In 1981 we intend to extend our work by taking the primary hardware modules 
now in wire wrap form and converting these to printed circuit boards. This 
effort will have two major benefits. First, it will allow us to show what 
performance margins exist at the system level. Performance margin cannot be 
demonstrated on the breadboard because of the high capacitance associated with 
the wire wrap technique. The second major benefit to design and fabricating 
the printed circuit boards is that we will be able to perform thermal and * 
vibration qualification level testing on a unit which much more closely 
resembles the final flight unit. 

Although the AFWAL/RCA CMOS/SOS microprocessor chip set was originally 
considered to be a high risk item, the fact that parts have been produced, 
tested and used in our computer system and the GPS program indicate that these 
parts will have a favorable future. The results we have obtained show that a 
CMOS/SOS computer can obtain the same performance levels as presently 
available bipolar spacecraft computer but at approximately 15% of their power 
consumption. 
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BACKGROUND 


OBJECTIVES:* 

QUANTITATIVELY DETERMINE HOW RECENT ADVANCEMENTS IN HARDWARE AND 
SOFTWARE** TECHNOLOGY CAN BE USED TO OBTAIN IMPROVEMENTS IN SPACECRAFT 
COMPUTER CAPABILITIES. 

CMOS/SOS INTEGRATED CIRCUITS 
SEMI -CUSTOM LSI DEVICES 
LEADLESS CARRIER PACKAGING 
MICROPROGRAMMING 

PASCAL. HAL. ADA. HIGER ORDER LANGUAGE 

*THIS WORK WAS CONDUCTED BY THE DENVER DIVISION UNDER INDEPENDENT 
RESEARCH AND DEVELOPMENT PROJECT AUTHORIZATION D-80D 
**RELATED PRESENTATION. "APPLICATION OF SOFTWARE TECHNOLOGY TO A 
FUTURE, SPACECRAFT COMPUTER DESIGN". IN SESSION III: MICROPROCESSOR 
SOFTWARE TECHNOLOGY 


BACKGROUND 


APPROACH: 

1978 REVIEW AVAILABLE STATE OF THE ART TECHNOLOGY 
DEFINE CANDIDATE ARCHITECTURES 

1979 PERFORM DESIGN OF ARCHITECTURES AND USE "PAPER 
EMULATION" TO OBTAIN QUANTITATIVE RESULTS 
SELECT "BEST" ARCHITECTURE 

1980 DEMONSTRATE SYSTEM USING BREADBOARD 

1981 BUILD AND TEST BRASSBOARD 
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AVAILABLE CMOS/SOS INTEGRATED CIRCUITS 


MSEC AND SAMAO CUSTOM DEVICES 

SAMSO ADVANCED COMPUTER TECHNOLOGY PROGRAM 

RAYTHEON 290X RESEARCH PROGRAM 

AIR FORCE MATERIALS LAB/RCA, MICROPROCESSOR CHIP SET 

CONCLUSION: 

OF AVAILABLE CMOS/SOS TECHNOLOGY AFML/RCA MICROPROCESSOR 
CHIP SET HAS BEST POTENTIAL FOR USE IN SPACEBORNE APPLICATIONS 


AFML/RCA CM0$/$0$ MICROPROCESSOR CHIP SET 
GPU TCS 129 

- General Processing Unit 

- 8-bit Parallel Slice 

- CONCATENATABLE 

- Fully Static 

- <125-ns Register-to-Re 61 Ster Add 
RAM TCS 150 

- Random-Access Memory 

- 256x9-bit Organization 

- <125-ns Access Time 

ROM TCS 075 

- Read-Only Memory 

- Fully Static 1029 bits 

- Mask-Programmable 

- <100-NS Cycle Time 


MUL TCS 196 

- 8x8-bit Multiplier 

- Expandable 

- Completely Asynchronous 

- Latched Input Operands 

GUA TCS 093 

- Gate Universal Array 
•- Customized Logic 

- 632 Gate-Level Complexity 

- 69 Pads 

- Proven Cell Library 

- 100-Mhz High-Speed Divider 

- 952^ 300 AND 182 GUAs Also Available 

"2910" Controller TCS 158 

- Microprogram Controller 

- Functional Equivalent to Am2910 
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GATE UNIVERSAL ARRAYS 

FIXED REGULAR PATTERN OF TRANSISTORS AND ROUTING PATHS. BY DEFINING 
INTERCONNECTIONS AMONG DEVICES. GUAs MAY BE CUSTOMIZED WITH LOGIC VERY 
SIMILAR TO THE WAY READ ONLY MEMORY IS CUSTOMIZED WITH DATA. 

MARTIN MARIETTA HAS DESIGNED THREE GUAs: 

TCS 092-8A3. GPU CONTROLLER 
TCS 092-8AA. MEMORY CONTROLLER 
TCS 093-8A5. SSI FUNCTIONS 

TCS 092-8A3 


FUNCTION: GPU CONTROLLER 

UTILIZATION: 368 INTERNAL CELLS 

62 I/O CELLS 
2 LOW Z CELLS 

CIRCUITS: A - REGISTER ADDRESS DECODE/ENCODE 

B - SIGN BIT FILE 

C - CONDITION CODE MUX 
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Decoder 





























MAC-16 COMPUTER DESIGN GOALS 


LOW POWER (< 20 WATTS) 

HIGH PERFORMANCE 0250 KOPS) 

MINICOMPUTER-LIKE INSTRUCTION SET ARCHITECTURE 

FIXED POINT AND FLOATING POINT ARITHMETIC 

PRIVILEGED AND USER MODE EXECUTION 

MULTIPLE LEVEL INTERRUPT HANDLING 

MEMORY MAPPED INPUT AND OUTPUT 

DIRECT MEMORY ACCESS 

MAC-16 COMPUTER PRIMARY HARDWARE MODULES 
SP-D32: CENTRAL PROCESSOR MODULE 

PIC-16: PRIORITY INTERRUPT CONTROLLER 

MMU-A: MEMORY BUS DRIVER/RECEIVER 

MMU-B: BASIC MEMORY MANAGEMENT UNIT 

MMU-C: EXTENDED MEMORY MANAGEMENT UNIT 

RAM-8E: HIGH SPEED 8K RANDOM ACCESS MEMORY 

RAM-16E: 16K RANDOM ACCESS MEMORY 

PROM-8; 8K PROGRAMMABLE READ ONLY MEMORY 

DMP-8: DIRECT MEMORY PROCESSOR 
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MAC-16 COMPUTER ARCHITECTURE 


CONTROL BUS 



HtMORT BUS 

SP-D52 CENTRAL PROCESSOR PRINCIPLE ELEMENTS 
FIXED POINT PROCESSOR 
FLOATING POINT PROCESSOR 
MICROPROGRAM CONTROL LOGIC 
MULTIPLIER CIRCUIT 
HIGH SPEED SHIFTER 
DATA FORMAT AND DEFORMAT LOGIC 
MEMORY INTERFACE 
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SP-D32 CENTRAL PROCESSOR MODULE OVERVIEW 



SPACECRAFT CENTRAL PROCESSOR COMPARISON 


FIXED POINT ADD (uS) 
FIXED POINT MUL (uS) 
FLOATING POINT ADD (uS) 
FLOATING POINT MUL (uS) 
TECHNOLOGY 
POWER (WATTS) 

IC COMPONENT COUNT , 
REMARKS 


AUTONETICS 

LITTON 

TELEDYNE 

DF224 

4516E 

MECA-43 

.8 

2.0 

1.6 

6. A 

5.4 

4.6 

- 

12.4 

9.9 

- 

23.0 

18.4 

PMOS 

TTL 

TTL 

15,5 

22 

. 25.5 

50 

107 

5 

24 BIT 


HYBRID 

FIXED 


PC KG 


IBM 

NSSC-II 

ITEK 

- ATAC-16 

MARTIN 

MAC-16 

1-7 

. 1.25 

2.0 

7.8 

5.5 

3.5 

20.8 

6.75 

16.5 . 

33.8 

17,0 

11.5 

TTL 

TTL 

CMOS/SOS 

100 

21 

2 

84 

7 

89 


JPL 

MEMORY 


POINT 















MAC- 16 HARDWARE STATUS 


REQMTS DESIGN 


BREADBOARD 


SP-D32: CENTRAL PROCESSOR MODULE 

PIC-16: PRIORITY INTERRUPT CONTROLLER • 

MMU-A: MEMORY BUS DRIVER/RECEIVER 

MMU-B: BASIC MEMORY MANAGEMENT UNIT 

MMU-C: EXTENDED MEMORY MANAGEMENT UNIT 

RAM-8E: HIGH SPEED 8K RANDOM ACCESS MEMORY 

RAM-16E: 16K RANDOM ACCESS MEMORY 
PROM-8: 8K PROGRAMMABLE READ ONLY MEMORY 

DMP-8: DIRECT MEMORY PROCESSOR 


COMPLETE 

COMPLETE 

IN PROGRESS 

COMPLETE 

IN PROGRESS 

1981 

COMPLETE. 

COMPLETE 

IN PROGRESS 

COMPLETE 

IN PROGRESS 

NOT SCHEDULED 

COMPLETE 

NOT SCHEDULED 

NOT SCHEDULED 

COMPLETE 

COMPLETE 

IN PROGRESS 

COMPLETE 

IN PROGRESS 

1981 

COMPLETE 

COMPLETE 

IN PROGRESS 

COMPLETE 

1981 

NOT, SCHEDULED 


DEMONSTRATION UNIT PRIMARY ELEMENTS 

MAC-16 COMPUTER ENGINEERING DEVELOPMENT UNIT 

SP-D32 CENTRAL PROCESSOR MODULE 

PIC-16 PRIORITY INTERRUPT CONTROLLER 

MMU-A MEMORY BUS. DRIVER/RECEIVER 

RAM-8E RANDOM ACCESS MEMORY 

PROM-8 PROGRAMMABLE READ ONLY MEMORY 

SUPPORT EQUIPMENT 

SERIAL I/O MODULE 
OPERATOR CONTROL PANEL 
WRITABLE CONTROL STORE 
GUA TTL CIRCUIT EQUIVALENTS 

MICROCOMPUTER - HARDWARE INTERFACE 

VAX 11/780 - SHOFTWARE HOST 


\ 
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Quantity 

Part 

Package 

43 

TCS 075 

24 HCC 

1 

TCS 158 

48 HCC 

5 

TCS 129 

48 HCC 

16 

TCS 196 

64 HCC 

4 

TCS 092-843 

64 HCC 

1 

TCS 092 844 

64 HCC 

19 

TCS 093-845 

64 HCC 

2 

Resistor Pack 

16 PP 

1 

E34 TCXO 

Hybrid 

2 

110 Lead Connectors 

— 

— 

Capacitors 

- 
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1981 HARDWARE^ OBJECTIVES ■ . 

BUILD AND FUNCTIONAL TEST OF PRINTED CIRCUIT BOARDS FOR PROCESSOR 
MODULE. MEMORY MANAGEMENT UNIT. PRIORITY INTERRUPT CONTROLLER. 
AND 8K MEMORY MODULE 

FUNCTIONAL TEST OF UK RAMs (TCS 1A6) FOR AIR FORCE MATERIALS LAB 
PERFORM PACKAGING MINI-QUALIFICATION TEST 


MAC-16 COMPUTER TEST SET UP 















MAC-16 PROJECTED FEIGHT UNIT DATA 
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EVOLUTION OF A STANDARD 
MICROPROCESSOR-BASED SPACE COMPUTER 

Manuel Fernandez* 

Litton Systems, Inc. 

Woodland Hills, California 


Stat'ting in 1976, an c'xisling in-invciUory comjniltM* harclwarc/solt \vaix‘ package 
(B-.l RFS/ECM) was ixrpackagL'cl and aj^plicd to midtij^lc missile? /spacr pi'ograms. 
Concurrent with the aj:>j3licalion edToi'ls, low-risk niodiCications were' made to the 
computef' from [:>rogram to program to take adv^■t^tag^‘ ol uvwvr, ad va rice cl technology 
and to mc‘et increasingly more' demanding rc'C)uirements (comi)utatic:)nal and memory 
capabilities, longer life, and fault tolc'ranl autonomy). 

In 1978, the; 2901 microj^roce'ssor chij) was incorpora le‘d ; and sinct' that time' advances 
in this mature, mu 1 1 i-sou rce'd , cjualified chip (specifically the* 290 IB) have bee'n 
used to improve* computational capability. 

This de? velo])me;n t establishes a base* te; t'xplore* the* use* of lU’wer mic I'op roce*ssors 
and to discuss curj'ent ti*e*nds from centixdi/A*d to distributed pi'oce*ssors . . Ke*y " 
diflciX'nces in computational arid memory ca[)abili ties , cjrbilal life*, and autonomous 
fault- toleran t i:>rovisions aia* compare*d. 

In summary, it is concluded that microj^roct'ssors hold jn‘omise* in a number of 
critical areas for future* sj)ace* c(;mputt*r aj:) p licat ion s . However, the* be*iu*fits of the* 
DoD VHSIC Program are* rec}uirt*d and the*' old pi'oli fe*ration preddem must be* reA'ised. 


%lembe*r AlAA 
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OUTLINE 

L UNIQUE REQUIREMENTS OF SPACE COMPUTERS 

2. STATE-OF-THE-ART SPACE COMPUTER (BASELINE) 

3. STATISTICS OF BASELINE COMPUTER 

4. DESIRED IMPROVEMENTS IN BASELINE COMPUTER 

5. CURRENT TRENDS AND TRADEOFFS IN COMPUTERS 

6. USE OF NEWER MICROPROCESSORS 

7. SUMMARY 


UNIQUE REQUIREMENTS 
OF SPACE COMPUTERS 

LOW POWER 

POWER IMPACTS 

- THERMAL BALANCE OF SATELLITE 

- RELIABILITY 

- POWER SOURCE CAPABILITY 

ENVIRONMENTAL DESIGN 

• VIBRATION (20 g RMS) 

• PYROTECHNIC SHOCK (3,000 g) 

• SPACE RADIATION (INCLUDING COSMIC RAYS) 

• EMI (MIL-STD-1541) 

• OUTGASSING.(SP’R-0022A AND JSC-08962) 

• POWER SOURCE (21V TO 35V DC) 

• THERMAL (-34C TO +71C "COLD PLATE") 


(CONT) 



UNIQUE REQUIREMENTS 
OF SPACE COMPUTERS (CONT) 

HIGH RELIABILITY (LONG ORBIT LIFE WITH HIGH PROBABILITY) 

• MATURE TECHNOLOGY 

• SIMPLICITY 

• WORST-CASE DESIGN 

• EXTRA-RELIABILITY PARTS 

• EXTRA-QUALITY WORKMANSHIP/INSPECTION 

• EXTENSIVE UNIT TESTING 

- RANDOM VIBRATION 

- THERMAL CYCLING 

- THERMAL VACUUM OPERATION 

- BURN-IN 

• ELIMINATION OF SINGL£-POINT FAILURE MODES 

- REDUNDANCY 

- FAULT-TOLERANT AUTONOMY 


SATELLITE THERMAL BALANCE IN ORBIT ^ 

MAX INTERNAL POWER DISSIPATION AVG. SURFACE TEMPERATURE 

8,200 WATTS 60“F 

13,000. WATTS 115°F 

ASSUMPTIONS 

SATELLITE - SPHERE, WHITE SURFACE, 10 FT DIAMETER , 
SIMPlf THERMAL MODEL UTILIZED 

HEAT SOURCES - SUN, EARTH, INTERNAL POWER DISSIPATION 
HEATSINK - SPACE 


♦THERMAL BALANCE EFFECTS 

- MAX INTERNAL POWER DISSIPATION 
POWER SOURCE CAPABILITY 

- RELIABILITY 


UNIT ACCEPTANCE TESTING 

L INSPECTION 

2. PERFORMANCE TEST 

3. RANDOM VIBRATION TEST 

DURATION 60 SEC/AXIS (ALL AXES) 

OVERALL 9.2 gRMS 

4. FUNCTIONAL TEST 

5. THERMAL CYCLING (THIS TEST TAKES APPROXIMATELY 160 HRS. OR 6.67 DAYS) 

EIGHT CYCLES TOTAL 
-lie TO +61C 

CONTINUOUS UNIT OPERATION 

6. FUNCTIONAL TEST 

(CONT) 


UNIT ACCEPTANCE TESTING (CONT) 

7. OPERATING ORBIT THERMAL VACUUM TEST 

12-HOUR SOAKS AT -IIC AND +61C, AFTER STABILIZATION, AND BEFORE 
FUNCTIONAL TESTS AT -IIC AND +61C 
UNIT OPERATING CONTINUOUSLY 

8. FUNCTIONAL TEST 

9. PIN-RETENTION TEST (Ml L-STD-1344A, METHOD 2014) 

10. FUNCTIONAL TEST 
IL BURN-IN TEST 

+6 1C CONTINUOUS 

UNIT OPERATING CONTINUOUSLY 

300 HR DURATION (12.5 DAYS) 

DIAGNOSTICS TEST 
GALWREC MEMORY TEST 

12. PERFORMANCE TEST 

13. POST TEST INSPECTION 
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REDUNDANT COMPUTER 



REDUNDANT COM P UTER 


VOLUME 

466 CU IN. 

WEIGHT 

26. 4 LBS 

POWER 

77.3 WATTS (96K -WORDS. ACTIVE) 

THROUGHPUT 

539 KOPS (GIBSON MIX) 

MEMORY 

128K-W0RDS (ACTIVE/STANDBY) 


(ADDRESSING TO 256K -WORDS) 

RELIABILITY 

0. 966 ■ 


(5 YRS) (WITH 64K-WOROS ACTIVE, 
16K-WORDS STANDBY) 






















STATISTICS 

OF BASELINE COMPUTER 


POWER BREAKDOWN 


CPU 26% 

MEMORY 19 

I/O 17 

S/T 62 

POWER SUPPLY 38“' 

TOTAL 100% 


"62% EFFICIENCY, WORST CASE DUE 
TO POWER SOURCE CHARACTERISTICS 



FLIGHT UNIT COST BREAKDOWN 


MATERIAL 64% 

ASSEMBLY 16 

TEST/INSPECTION 20 

TOTAL 100% 


FLIGHT UNIT COST BREAKDOWN 


CPU 11% 

MEMORY ' 59" 

I/O 6 

POWER SUPPLY 6 

OTHER 18 


100 % 

"128K-W0RDS TOTAL (ACTIVE/STANDBY) 



FAILURE RATE BREAKDOWN 


CPU 38% 

MEMORY 23'^- 

I/O 29 

POWER SUPPLY 8 

OTHER 2 

TOTAL 100% 


= REFLECTS FAULT -TOLERANT MEMORY EFFECTS 
(THIS IS RESIDUAL) 


SPACE COMPUTER PROJECT 
COST BREAKDOWN 


FLIGKT UNIT 

18% 

SUPPORT 

40-' 

SOFTWARE 

42 

TOTAL 

100% 


'INCLUDES SPARE FLIGHT UNIT 


SUMMARY 


MICROPROCESSORS COULD IMPACT BASELINE COMPUTER, 
WHOSE STATISTICS YIELD: 

• CPU 26% OF POWER 

(EXCLUSIVE OF P. S. DISSIPATION PENALTY) 

• CPU 11% OF FLIGHT UNIT COST . 

• CPU 38% OF FAILURE RATE 

• SOFTWARE 42% OF PROJECT COST 


DESIRED IMPROVEMENTS 
(IN BASELINE) 

• FAULT-TOLERANT AUTONOMY 

• HARDER RADIATION TOlfRANCE 

- TOTAL IONIZING DOSE 

- SINGLE EVENT UPSETS 

• LOWER POWER 

• IMPROVED COMPUTATIONAL CAPABILITY 

• LONGER ORBIT LIFE WITH HIGH PROBABILITY 


• LOWER SOFTWARE COSTS 


CURRENT TRENDS 


• CENTRALIZED SIMPLEX COMPUTER ARCHITECTURES DEMANDING HIGHER WORKLOAD CAPABILITIES 

• DISTRIBUTED SYSTEMS WITH FOLLOWING INTERPRETATIONS: 

(FALL OUT OF POINT-OF-USE SYSTEMS. RESOURCE-SHARING NETWORKS. MULTI PLf 
• PROCESSOR SYSTEMS ARCHITECTURES) 

• MULTIPROCESSORS (TO HANDLE LOAD). STILL CENTRALIZED 

• DEDICATED COMPUTERS (PER FUNCTION). LOOSELY FEDERATED 

• FEDERATED COMPUTER ARCHITECTURE WITH SYSTEM MGR AND DEDICATED SUBSYSTEM 

COMPUTERS 

• DISTRIBUTION OF TASKS/WORKLOADS AMONG NONOEDICATED COMPUTERS 

• COMBINATIONS OF ABOVE 


TRADEOFFS 

CENTRALIZED SYSTEM ADVANTAGES ^' 

• MORE EFFICIENT LOAD SHARING AND LOWER RESPONSE TIME 

• GREATER FLEXIBILITY 

• MORE EFFICIENT COMMUNICATION 

• LESS REDUNDANCY OF STORAGE 

• GREATER TOTAL COMPUTATIONAL CAPABILITY 

• HIGHER TOTAL SYSTEM RELIAB ILITY 

• MORE EFFECTIVE USE OF REDUNDANCY 

DEDICATED SYSTEM ADVANTAGES 

• LESS COMPLEX SOFTWARE 

• HIGHER RELIABILITY FOR INDIVIDUAL FUNCTIONS 

"INCLUDES INTEGRATED, MULTIPROCESSOR, CENTRALIZED SYSTEMS 



SUMMARY 


MICROPROCESSORS COULD IMPACT BASELINE COMPUTER, 
WHOSE CENTRALIZED COMPUTER ARCHITECTURE YIELDS: 

• MORE COMPIEX SOFTWARE 

• LESS RELIABILITY FOR INDIVIDUAL FUNCTIONS 


UTILIZATION 

OF NEWER MICROPROCESSORS 



MICROPROCESSOR POTENTIAL IMPACT 
(ON BASELINE) 


OIM BASELINE STATISTICS OF : 

• CPU 26% OF POWER 

• CPU 11% OF FLIGHT UNIT COST 

• CPU 38% OF FAILURE RATE 

• SOFTWARE « OF PROJ. COST 

ON DESIRED BASELINE IMPROVEMENTS OF : 

• LONGER ORBIT LIFE 

• FAULT-TOLERANT AUTONOMY 

• IMPROVED COMPUTATIONAL CAPABILITY 

• LOWER SOFTWARE COSTS 

• HARDER RADIATION TOLERANCE 


ON CENTRALIZED SYSTEM ARCHITECTURE 
DISADVANTAGES 

• MORE COMPLEX SOFTWARE 

# t£SS RELIABILITY PER FUNCTION 


• PROMISING 

• PROMISING 

• PROMISING (BUT NOT YET MATURE) 

• PROMISING (BUT NOT ASSURED) 

• PROMISING 

• POTENTIAL NOT CHAR 

• PROMISING 

• DEPENDENT ON REUSE OF SOFTWARE 

• MICROPROCESSOR TECHNOLOGIES AND HIGHER 
LEVELS OF INTEGRATION OF FUNCTIONS ON A 
CHIP ARE NOT CONDUSIVE TO RADIATION 
HARDENING TOLERANCE 

(DoD VHSIC PROGRAM WILL HELP) 


• PROMISING 

• PROMISING 


SUMMARY 

• MICROPROCESSORS BEING DRIVEN BY LARGE COMMERCIAL MARKETPLACE 

• MICROPROCESSORS LOOK PROMISING IN A NUMBER OF CRITICAL AREAS 

FOR FUTURE SPACE COMPUTER APPLICATIONS 

• DoD VHSIC PROGRAM COULD HELP SOLVE CRITICAL RADIATION 

HARDENING PROBLEMS 

• REUSE OF SOFTWARE A CRITICAL ITEM 

• USE OF LARGE NUMBER OF MICROPROCESSOR TYPES FOR FUTURE SPACE 
APPLICATIONS NOT WISE, AND CHOICE WILL BE DIFFICULT 

• FAULT-TOLERANT AUTONOMY NEEDS ATTENTION 


KEY AREAS NEEDING STRESS 

REDUNDANCY MANAGEMENT 
FAULT TOLERANCE 
SOFTWARE DEVELOPMENT 


V 
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MICROPROCESSORS FOR IMAGING SEEKERS 

R. G. Hix and D. W. Smith 
General Dynamics 
Pamona, California 

Operational imaging seekers, such as AIRIS and FAIRS (air-to- 
air IR seekers) require high-speed, high performance, low-power, 
multi-processors (system throughput in excess cf eighteen million 
operations per second with CMOS power consumption). This paper 
addresses the three areas which must be investigated to achieve 
this combination of performance, namely, device technology, 
microprocessor architecture, and multi-processor architecture. 

The results of a comprehensive microprocessor survey are presented, 
which identified the ATMAC microprocessor (a high-speed, low- 
power CMOS/SOS microprocessor produced by RCA*s Advanced Technology 
Laboratory) as the best candidate for imaging seeker applications. 
Capabilities of the CMOS/SOS technology are discussed along with 
problems which had to be overcome to successfully apply this 
technology to imaging seekers. Capabilities, problems encountered, 
and their solutions in the application of ATMAC microprocessors 
to imaging seekers are discussed. The results of a multi-processor 
architecture selection trade study are presented. Also, the 
capabilities and operating characteristics of ideal microprocessor 
and multi-processor architectures for use in imaging seekers are 
detailed, as well as their implications to multi-programming. The 
implemented multi-processor system is compared with the desired system, 
and desirable advances in device technology, microprocessors, and 
multi-processor architectures are highlighted. 
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MODULAR MISSILE BORNE COMPUTERS 

R. Ratnseyer, R. Arnold, H. Applewhite and R. Berg 
Honeywell Systems and Research Center 
Minneapolis, Minnesota 

A 

The increasing real time signal and data processing loads on-board 
BMD interceptors cannot be met with currently available and flyable 
processors. The Modular Missile Borne Computer is being developed 
to provide a solution to that problem through the use of a 
collection of microprocessors in a distributed processing system. 

This paper discusses the Modular Missile Borne Computer's architecture 
with emphasis on how that architecture evolved from a careful 
analysis of both the physical constraints and the processing require- 
ments. The development techniques used are generally applicable 
to real-time data processing systems and have resulted in the 
achievement of one of our most significant design goals. This 
goal is a modular, flexible, extensible system capable of adapting 
to evolving BMD problems as well as others where an ultra-high 
performance distributed processor is desirable. 

The general objective for the MMBC program is the development of 
a data processing system which lends itself readily to system 
growth, reconfiguration and changes in application or environment. 
Given the constraints and requirements imposed by the BMD threat, 
scenarios and environmental considerations, four driving architectural 
considerations result: 

• The required processing is real time. 

• There is a massive quantity of data and it is received 
at a rapid rate. 

• A high degree of modularity, flexibility and potential 
for growth is desired in MMBC. 

• MMBC must be capable of performing in an extremely hostile 
operating environment (e.g. shock, vibration, temperature, 

^nd nuclear) . 


229 


DATA PROCESSING IN A MIDCOURSE SYSTEM 



j 
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COMPUTER 



HIGH LEVEL PROCESSOR STRUCTURE 



TOTAL DP LOAD IS COMPOSED OF 
MANY SMALL, INDEPENDENT LOADS 
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E APPLICA 
AYS TO PE 
ER 


lOS/DP 


14 SIND'S 


PULSE MATCH 


ALLOW MAXIMUM USE OF LSIC HARDWARE 

- MINIMIZES SIZE/WEIGHT/POWER/INTERCONNECTS 

SPECIAL PURPOSE OPERATION CAN BE ACHIEVED THROUGH MICROPROGRAMMING 

SIMULTANEOUS OPERATION OF MANY REAL TIME HARDWARE UNITS DRASTICALLY 
REDUCES NEED FOR MULTIPROGRAMMING 

- REDUCED SOFTWARE COST 

- REDUCED OVERHEAD TIME 

ALLOWS MAXIMUM MODULARITY TO BE ACHIEVED WHICH IMPROVES 

- FAULT TOLERANCE 

-- FLEXIBILITY /ALTERABILITY 
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APPROXIMATE 

CAPABILITIES AND REQUIREMENTS 


PROCESSING SECTION 

PROCESSOR 

CONFIGURATION 

REQUIREMENT 

CAPABILITY 

PREPROCESSING ANO 
BULK FILTERING 




OMX TO PULSE 

14SIMD 

22 MIPS 

~40 MIPS* 

MATCH 

(1 TO 3 MIPS EA) 



PULSE MATCH 

4GPW/SPECIAL 
ARITHMETIC 
(15 MIPS FOR PULSE 
MATCH; 1 MIPS 
OTHERWISE) 

43 MIPS 

45 MIPS 




TRACKING AND 

3GP 

151 KIPS 

3 MIPS 

DISCRIMINATION 

(1 MIPS EACH) 



GUIDANCE NAVIGATION 

1 GP 

185 KIPS 

500 KIPS 

AND CONTROL 

(500 KIPS) 



j TOTAL CAPACITY 


88.5 MIPS 


•HIGH THROUGHOUT REQUIRED TO ABSORB OVERHEAO AND SATISFY REAL-TIME RESPONSE REQUIREMENT. 

EACH COMPUTER IN MMBC IS "TUNED" TO PERFORM WELL IN ITS AREA OF APPLICATION. 

E.G., MULTIPLE DATA STREAM PROCESSORS IN BULK FILTERING; PIPELINED. FAST 
ARITHMETIC UNIT IN PULSE MATCH. 


CHARACTERISTICS OF HARDWARE MODULES 


GENERAL PROCESSING ELEMENT (16 BITS) 

1 MIPS 

SIMDPE(3ALU‘S) 

3 MIPS 

VOA PROCESSOR 

15 MIPS/5 MIPS 

LOCAL MEMORY (3 PORT RAM) 

READ ACCESS TIME 

270 ns 

WRITE ACCESS TIME 

75 ns 

COMMON BULK MEMORY 

READ 

375 ns 

WRITE 

140 ns 

CYCLE 

425 ns 

GLOBAL BUS (3 BUSES) 

TRANSFER RATE 

1 MWOROS/S 
1 MWOROS/S 


CAN HANDLE 40 K TRACKS/SEC/GLOBAL BUS 
UTILIZATION 60% 



tDEALIZED SHARING-THROUGHPUT 
VERSUS NUMBER OF PROCESSORS 



234 


1/3 a oj indHonoaHi 




235 


AUGMENTATION EXAMPLES 





SOFTWARE ARCHITECTURE 
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EXAMPLE OF SIZE REDUCTION FOR 
PACKAGING OPTIONS 


UJ 



248 










EXAMPLE OF HYBRID MMBC SYSTEM 
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MODULAR MISSILE BORNE COMPUTERS 
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INSW HEAD FUNCTIONS (ESPECIALLY THOSE 

DUE TO MULTI COMPUTER 
CONFIGURATION 
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MICROPROCESSOR-CONTROLLED TELEMETRY SYSTEM 

Paul Holtzman and Stephen D. Hawkins 
RCA 

Princeton, New Jersey 

A spacecraft telemetry unit completely controlled by a 
microprocessor was developed at RCA Astro-Electronics. 

This unit, the Programmable Information Processor (PIP), 
must sample 650 sources of analog and discrete house- 
keeping information plus digital data generated by space- 
craft computers. The data must be formatted for serial 
transmission to spacecraft data storage devices or direct 
transmission to the ground via a telemetry beacon link. 

The choice of microprocessor to accomplish these tasks 
was influenced by requirements for 1) low power, 2) 
survival in radiation environment, and 3) instruction ex- 
ecution time of 6 microseconds. The RCA CDP1802 CMOS 
microprocessor was ultimately selected. The entire hard- 
ware system including ROM and RAM memories utilizes CMOS 
technology and dissipates only 5 watts of power. Many 
commandabl e modes of operation are possible with the PIP. 
Four major modes have differing format structure, sampl- 
ing rates and output data rates. Submodes enable 
selected data channels to be uniformly sampled at higher 
sampling rates for diagnostic purposes and also enable a 
dump of memory data from various spacecraft computers and 
of the PIP itself. The sampling sequences for housekeep- 
ing telemetry points are determined by preassigned tables 
within the PIP software. An additional feature is the 
capability to restructure these tables by a memory load. 
Complete dual redundancy is employed in the PIP such that 
no single failure may compromise the mission requirements. 
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MICROCOMPUTER ARRAY PROCESSOR SYSTEM 

Kenneth D. Slezak 
Goodyear Aerospace Corporation 
Akron, Ohio 

The Microcomputer Array Processor System (MAPS) is a program- 
mable multiprocessor computer system designed for Electronic 
Warfare applications for the Air Force Avionics Laboratory (AFAL) . 

The system architecture retains many of the classic multiprocessor 
design concepts including a master-slave relationship among its 
microprocessors under the control of a single operating system in 
a tightly coupled structure. Each processor is a 32-bit programmable 
computer with its own dedicated memory and a capability to execute 
approximately 4 million instructions a second. In addition to the 
dedicated memory, each processor can communicate with niomerous 
banks of common memory (referred to as global memory). The various 
global memory modules and their communication structure serve to 
tie the individual processors together in a symmetrical multi- 
processor computer architecture. The multiprocessor system is 
modular and can contain as few as 2 and as many as 8 processors 
coupled with from 1 to 16 banks of global memory and executes 32 
million instructions per second. Expansions beyond these limits are 
possible if every processor does not have to have access to every 
global memory module. Currently, a 4 processor system (with 3 
banks of global memory) is installed at Wright Patterson Air Force 
Base for use by AFAL. This system will be expanded to 6 processors 
during 1980. This multiprocessor subsystem is approximately 1.6 
cubic feet and consumes under 400 watts of power. 
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MAP PROCESSING FUNCTIOMS 


» ESTABLISHES FILE OF ACTIVE EMITTERS 
. DETERMINES PRI 

. REPORTS PRESENCE OF NEW EMITTERS. 

• TRACKS ESTABLISHED EMITTERS 

. TRACKS IN TIME AND ANGLE 

• . DELETES INACTIVE EMITTERS 

• CAPABILITY FOR 

.. SCAN RATE DETERMINATION 
. EMITTER TYPE IDENTIFICATION 
. , RECEIVER CONTROL 
. POWER MANAGEMENT 


PDS SYSTEM 
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MICROPROGRAM SEQUENCER 
BLOCK DIAGRAM 
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MICROPROCESSOR SLICE BLOCK DIAGRAM 
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INSTRUCTION EXECUTION SPEED 


TYPE 

INSTRUCTION 

EXECUTION (nSec) 

0 

REGISTER/REGISTER 

250 OR 325 

1 

INPUT/OUTPUT 

350 OUTPUT 
m INPUT 

2 

REGISTER/imEDIATE 

350 

3 

READ/l/RITE PROGRAfI MEMORY 

525 READ 
650 WRITE 

N 

EXTERNAL FUNCTION CONTROL 

350 

5 

INTERRUPT CONTROL 

m 

6 

. PC STACK CONTROL 

300 

7 

CONDITIONAL BRANCH 

200 NO BRANCH 
300 BRANCH 
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COMPARISOH OF AiPROCESSORS 



AMO 

AM2901 

NMI 

MM6701 

Intel 

3002 

TI 

SBP0400 

Motorola 

M10800 

Slice Width 

4 bits 

4-bits 

2-bits 

4-bits 

4-bits 

Cycle Time 
(Register to 
register; Read, 
Modify, Write) 

100ns 

200ns 

150ns 

1000ns 

55ns 

Power 

Dissipation 
(4 bits) 

m 

1.12W 

1.45W 
(2 X 0.73) 

m 

1.3W 

Addressable 

Registers 

16 

16 

11 

8 

1 (External 
4-256) 

Register 

Addressing 

Mode 

Two- 

Address 

Two- 

Address 

Single- 

Address 

Single- 

Address 

Single- 

Address 

Nusdber of 
Microcode 
Control Inputs 

9 

8 

7 

9 

16 

Primary 

Arithmetic 

Functions 

R + S 
R - S 
S - R 

R + S 
R - S 
S - R 

Rc+ S 


R -f S 
R - S 
S - R 

Primary 

Logic 

Functions 

5 

3 

3 

8 

6 - BCD 
8 - Binary 

Possible Source 
operand Combina- 
tion to ALU 

203 

203* 

24* 

33* 

6-262 

Possible ALU 

Destination 

Registers 

17 

17 

12 

10 

2 - 258 

Flags 

0 

Carry 

Overflow 

Zero 

Negative 

Carry 

Overflow 

Zero 

F«llll 

Carry 

Carry 

Carry 

Overflow 

Zero 


*Mot all functions can be performed on all operand pairs. 
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PROCESSING TIME (MSEC) 


DISTINCTIVE CHARACTERISTICS 


• Two-address architecture - 

- Independent simultaneous access to two working 
registers saves machine cycles. 

• Eight-function ALU — 

Performs addition, two subtraction operations, and 
five logic functions on two source operands. 

• Flexible data source selection - 

ALU data is selected from five source ports for a 
total of 203 source operand pairs for every ALU 
function. 

• Left/right shift independent of ALU — 

Add and shift operations take only one cycle. 

• Four status flags — 

Carry, overflow, zero, and negative. 

• Expandable — 

Connect any number of Am2901 's together for longer 
word lengths. 

• Microprogrammable — 

Three groups of three bits each for source operand, 
ALU function, and destination control. 


HAP PERFORMANCE 
(42 EMITTER ENVIRONMENT) 
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